e-business - développement

E-‐business : stratégie marketing et développement 2012-‐2013

Manon Cuylits

Manon Cuylits Master 1 2012-‐2013

2 Développement de systèmes e-‐business

PART IE 1 : DEVELOPPEMENT DE SYSTEMES E -‐BUS INESS

PLAN

• Projet de développement d’un système e-‐business o Processus de développement o Spécificités des projets e-‐business o Cycle de développement

• Lancement du projet o Définition de la portée du système o Gestion des acteurs o Gestion du projet

• Etude d’opportunité • Spécification

o Définition de la spécification o Diagramme de cas d’utilisation o Diagramme d’activité o Diagramme de contenu o Diagramme d’interface o Etude de cas

• Réalisation o Conception et mise en œuvre o Outils de développement

§ Outils de développement classiques § Générateurs de sites § Package et content management

o Techniques clés § Pages dynamiques § Interopérabilité des systèmes

• Mise en production • Test • Exemple : Rational Unified Process • Maintenance et promotion • Sécurité

o Etat et enjeux o Solutions o Exemple de procédure de sécurité


3 Thierry Van den Berghe

1. PROJET DE DEVELOPPEMENT D’UN SYSTEME D’E-‐BUSINESS

ð Processus de développement ð Spécificités des projets e-‐business ð Cycle de développement

PROJET DE DEVELOPPEMENT E-‐BUSINESS

Le développement d’un système e-‐business suit un processus de développement organisé et constitue un projet pour l’organisation.

On souhaite créer un système e-‐business dans notre organisation, (exemple : site de vente en ligne, site communautaire, etc.) il faut que ce projet soit motivé, qu’on puisse démontrer que ce projet produit de la valeur ajoutée. Tout projet doit s’inscrire dans une stratégie et être cohérent.

Le développement d’un système e-‐business suit un processus organisé selon des étapes principales. On construit par étapes. La règle est de réfléchir avant d’agir, essayer d’adopter une approche industrielle dans le développement d’un logiciel. (Cf. ingénierie logicielle plus bas).

Le développement d’un système e-‐business constitue un projet pour l’organisation :

-‐ opérationnaliser la stratégie -‐ gérer les ressources -‐ gérer les contraintes de résultat, de budget et de délai

L’INGENIERIE LOGICIELLE : DEFINITION & DEMARCHE

L’ingénierie logicielle consiste à « appliquer une démarche systématique, disciplinée et quantifiable pour le développement d’un logiciel, un système e-‐business ». è élaboration de processus de développement.

Un projet de développement suit un processus qui est généralement organisé en phases successives.

Démarche générique :



En général on trouve 4 grandes phases :

Réflexion préalable au commencement du projet :

1. comprendre le problème Par exemple : quels sont les besoins au niveau logistique pour construire un nouveau bâtiment

2. planifier des solutions.

Réalisation concrète de ce qui a été imaginé au préalable :

3. exécuter le plan. 4. Evaluer le résultat : phase de retour sur expérience : quand le projet est terminé on

fait un bilan de ce qui a fonctionné ou non

On distingue 4 phases et lors de ces phases on réalise une série d’activités (exemple : interview des utilisateurs pour connaître leurs besoins). Certaines activités peuvent avoir lieu à des phases différentes. Les tests de qualité interviennent en permanence par exemple. Ce sont des activités transversales qui ont lieu tout au long du projet.

PRINCIPES DE BASE DE L’INGENIERIE LOGICIELLE

• L’intention première d'un système est de donner de la valeur aux utilisateurs

Un système est souvent développé pour une autre personne è collaborer, communiquer et documenter.

Un système, développé par des informaticiens, qui n’est pas directement en connexion avec la demande des utilisateurs ce n’est pas une bonne chose. Tout le projet est guidé par une demande des utilisateurs. Ce n’est pas le cas pour la production d’autres types de bien mais c’est typique du logiciel.

• garder le système simple = ligne de conduite intellectuelle

Un système simple est plus facile à développer, à maintenir et à utiliser. Néanmoins, travailler à la simplification d'un système prend du temps et est ardu.

• rester ouvert au futur et intégrer la flexibilité

Les besoins des utilisateurs évoluent è le système doit pouvoir être adapté facilement!

Les systèmes informatiques doivent suivre les attentes des utilisateurs et dans le business la manière dont on traite les affaires évolue constamment. Il faut pouvoir évoluer en proportion.

Exemple du bug de l’an 2000 : en 1999 les informaticiens se sont rendu compte qu’il fallait gérer le fait qu’on allait passer de 2 chiffres à 4 chiffres, gérer le siècle. Les systèmes informatiques de l’époque étaient très mal prévus pour intégrer des changements.

Ce n’est pas facile de construire un système qu’on peut faire évoluer. Un logiciel on le modifie encore une fois qu’il est « fini », ce n’est pas le cas des voitures par exemple.



• encourager la réutilisation des composantes o Exemple : construire un système en assemblant des composants existants

Dans certaines industries, comme celle de l’automobile, on essaye de standardiser les composantes, les intégrer dans des ensembles plus vastes, mais dans le cas des logiciels cette standardisation a du mal à s’imposer et cela représente un cout significatif.

1. PROCESSUS DE DEVELOPPEMENT

Le Processus de développement: c’est un canevas qui structure et guide les informaticiens dans la production de logiciels, montre les différentes étapes à parcourir. Si on souhaite construire une maison on va suivre différentes étapes claires et structurées, c’est pareil. La production de la plupart des biens matériels et immatériels suivent un processus d’ingénierie bien précis.

Processus Ø Quelles phases & tâches ? Ø Quels délivrables ? Ø Quels rôles ? Ø Etc.

Tâches managériales Ø Planification Ø Gestion des ressources Ø Gestion des risques Ø Gestion de la qualité Ø Etc.

Tâches techniques Ø Spécification du système Ø Modélisation Ø Programmation

Le processus c’est un ensemble d’étapes réalisées pour atteindre un but précis. Dans les processus de développement de système e-‐business on distingue deux grandes dimensions : une dimension managériale et technique.

• Tâches managériales :

L’aspect managérial englobe tout ce qui concerne la gestion de projet, on va le retrouver dans les projets de toute nature. On retrouve là dedans des taches de planification, de gestion des risques, de gestion des ressources, et de gestion de la qualité, entre autres.

Exemple de tâches managériales : planification des activités, constitution d’une équipe

• Tâches techniques :

Elles contribuent directement à la production du produit final. On y retrouve par exemple la spécification du système, la modélisation et la programmation.



Exemple de tâches : modélisation du système à construire, programmation

Parallèle avec la construction d’une maison : tracer des plans pour le bâtiment, le gros œuvre, etc. sont des taches techniques mais au niveau managérial, on réalise plutôt des activités comme le suivi budgétaire etc.

Autrement dit, un processus est un ensemble d’activités coordonnées (tâches techniques et managériales/de gestion de projet) pour atteindre un but : le projet informatique (application d’un processus donné pour développer un système d’information).

Le processus va spécifier :

• les phases du projet et son cycle de développement ; • les tâches à réaliser au sein de chacune des phases et leur enchaînement dans le

temps ; • les produits à produire et fournir et • les différents rôles à assumer

TYPES DE PROCESSUS

• Processus inexistant

Just do it ! Certains projets sont réalisés sans processus. Par exemple si on doit développer un petit site web, on ne va pas mettre en activité un processus long, on va directement produire le site.

Dés qu’on s’engage dans un projet plus important, 2 manières de travailler : processus prescriptif ou adaptatif.

• Processus prescriptifs o planification complète des activités puis exécution du plan o les activités sont réalisées une seule fois en séquence o vue globale du projet dès le départ mais travail de révision potentiel en cas

de changements

Analogie avec le blocus: si on travaille selon un processus prescriptif, on va planifier notre blocus et session d’examen de manière précise et jusqu’au bout, on sait combien de temps d’étude on a prévu pour chaque cours, chaque jour. On connait toutes les tâches à réaliser, l’objectif à atteindre, mais ce processus n’intègre pas facilement le changement. Si on est malade et qu’on ne sait pas travailler le 3ème jour, on doit tout re-‐planifier pour s’adapter au changement.



• Processus adaptatifs o planification réduite et gestion intégrant le changement o des itérations répètent certaines activités plusieurs fois

§ Exemple : plusieurs prototypes successifs sont construits et évalués jusqu'à répondre correctement à la demande de l'utilisateur

§ Exemple : méthodes Agile

C’est la tendance ces dernières années. On va avoir une planification générale et peu détaillée, les grandes phases sont détaillées mais la planification détaillée n’intervient qu’à très court terme, pour quelques jours. On se dit qu’on ne sait pas tout connaître dés le départ. C’est donc de la planification à court terme. Pour développer des sites web ca marche super bien car c’est très compliqué d’anticiper précisément les attentes de l’utilisateur, elles se précisent au fur et à mesure.

CONTREPIED DE LA PLANIFICATION : METHODES AGILE

Principe des méthodes Agile: les besoins des utilisateurs, le processus de développement et le logiciel à produire émergent progressivement au cours du projet

• planification peu détaillée • cycles courts • système découpé en différents modules • collaboration étroite avec les utilisateurs et feedback immédiat è accent très

important sur la collaboration entre l’utilisateur et l’informaticien • livraison régulière de parties du système (exemple : développement du module

« présentation des produits », puis du module « prise de commande », puis du module « suivi des commandes », etc.)

http://www.agilealliance.org, http://www.extremeprogramming.org

PHASES & ACTIVITES TYPIQUES DE DEVELOPPEMENT



PREMIERE PRESENTATION DES ACTIVITES CLES

Il y 4 grandes phases qu’on retrouve dans tous les cycles de développement :

1. Comprendre le problème 2. Planifier une solution 3. Exécuter le plan 4. Evaluer le résultat

On va détailler les activités pour chacune de ces phases:

1) comprendre le problème :

• lancer le projet : préciser/déterminer les objectifs principaux du système qu’on veut construire, les contraintes, les ressources et la planification du projet è cadrer le projet

• étudier l'opportunité : réfléchir à l’opportunité qu’il y aurait de lancer le projet : retours supérieurs aux investissements è évaluer les apports et décider de la réalisation du projet

• spécifier le système (de manière assez détaillée): décrire les facilités attendues du système à partir de besoins exprimés par les utilisateurs

2) Planifier une solution & 3) Exécuter le plan

• concevoir et mettre en œuvre le système (plus technique) : réaliser le système en concevant d'abord la solution technique puis programmant le système (choisir les techniques les plus adaptées)

• mettre en production : transférer le système aux utilisateurs (réaliser le système, programmer, le mettre en production)

4) Evaluer le résultat :

• tester le système : vérifier la qualité et corriger les défauts (en réalité, cette activité est faite en permanence)



2. SPECIFICITES DES PROJETS E-‐BUSINESS

• application e-‐business o logiciel de traitement de données accessible par Internet. Visent à produire

et transformer de l’information. § exemple : Web-‐banking, enregistrement de commandes

• site e-‐business o ensemble de contenus relativement stables accessibles par Internet

§ exemple : site de présentation d'une entreprise (site vitrine)

• système e-‐business o ensemble de composants accessible par Internet. Ces systèmes visent à

diffuser de l’information. Par contre les applications e-‐business visent à produire et transformer de l’information.

§ exemple : système combinant un site vitrine et une application de vente

EXEMPLES D’EXIGENCES SPECIFIQUES DES APPLICATIONS E-‐BUSINESS

1. Rendre une application attractive

Surtout pour les applications de commerce électronique. Il est très important d’avoir un système attractif. Il faut que les accès soient adaptés à des profils d’utilisateurs variés

• Exemple : le designer (ou un graphiste) développe des maquettes de site • Exemple : l'ergonome améliore la facilité d'utilisation d'une application

è ergonomie = facilité d’utilisation

Exemple ci-‐dessus : Site a gauche peu attirant et a droite beaucoup plus dynamique, mieux foutu, l’effort d’ergonomie et plus important que pour le site de gauche.



2. prévoir des mécanismes de contrôle collaboratifs des données

Beaucoup de systèmes de l’internet sont à diffusion mondiale. Il est très important de contrôler l’information diffusée sur les sites web, surtout quand on a une construction collaborative de contenu, comme dans le cas des forums. Pour les sites de diffusion d’informations, il faut définir des mécanismes de validation des contenus, de contrôle des différents messages etc. La qualité d’un système Web dépend en grande partie de son contenu

• Exemple : le gestionnaire de contenu met à jour les news d'une page d'accueil • Exemple : le modérateur contrôle le ton des messages postés sur un forum

3. assurer la sécurité

L’Internet est un espace public accessible à des hackers. è Au départ les technologies de l’internet n’ont pas été conçues pour être correctement sécurisées. Il existe une série de mécanismes qui sécurisent jusqu’à un certain point les infos qui circulent sur le net mais on est encore loin de la perfection. Internet : on est la cible potentielle de milliers de hackers qui n’ont que ca à faire : attaquer les systèmes etc. On n’a pas droit à l’erreur, si un pirate rentre sur notre système les effets peuvent être désastreux.

• Exemple : un expert sécurité met en place des protections contre le piratage

4. assurer la performance

Dans le cas des systèmes orientés réseau et massivement multi-‐utilisateurs, la charge d’un système est imprévisible et peut être très variable au cours du temps, surtout dans le cas d’un site de vente en ligne. On ne sait pas dire combien d’utilisateurs vont utiliser notre système en même temps. Cela peut lancer des problèmes de performance critiques (exemple : on lance une super promo, des tonnes de clients prennent le site d’assaut et cela crée des problèmes, parfois même pour une durée très courte). Faut il investir en infrastructure pour faire face à cela ? Le débat n’est pas évident.

• Exemple : un web master adapte l’infrastructure en fonction du trafic



3. CYCLE DE DEVELOPPEMENT D’UN LOGICIEL

• le développement d’un logiciel est progressif o la complexité impose une découpe o un projet est souvent organisé en phases o une phase est le lieu d’activités

Le développement est progressif. Pourquoi ? Aujourd’hui les demandes des utilisateurs et les technologies qu’on veut mettre en place sont tellement complexes qu’on doit structurer en différentes phases.

• le cycle de développement précise les interrelations entre les phases : o dans quel ordre et à quelle fréquence exécuter les phases? o quels critères pour passer d’une phase à l’autre? o quels délivrables pour chaque phase?

Le cycle de développement précise les interrelations entre les différentes phases. Dans quel ordre enchainer les phases ? Faut-‐il exécuter les phases plusieurs fois ? Qu’est ce qui déclenche le passage d’une phase à l’autre, etc.

CYCLE DE DEVELOPPEMENT EN CASCADE

Cycle de développement en cascade : On enchaine les différentes phases, une seule fois : l’output est déversé en tant qu’input dans la phase suivante. On enchaine de manière linéaire

Ø la spécification du système Ø la conception du système Ø la mise en œuvre du système Ø le test du système Ø la mise en production du système



EVALUATION DU CYCLE EN CASCADE

1. Ce cycle en cascade, en une seule séquence n’est pas très réaliste, essentiellement parce que la spécification du système (= la description des attentes de l’utilisateur) n’a lieu qu’à la première étape puis qu’on n’y retourne pas. Cela suppose que l’utilisateur connaît exactement ses attentes et qu’elles n’évoluent pas, ça ne se passe pas comme cela dans la réalité. Il est difficile pour les utilisateurs et les spécialistes de cerner les besoins, en outre, dans un environnement changeant, ces besoins sont instables. Pour finir, les systèmes à construire sont complexes.

2. Mise en production selon un mode "big bang" • lourdeur des tests concentrés en fin de cycle • les risques restent présents très tard dans le projet, car peu de tests en début de

projet

3. Limité aux projets réduits en taille et en durée de développement

PLUSIEURS APPROCHES POUR MAITRISER LA COMPLEXITE

Pour maitriser la complexité d’un développement, il existe plusieurs approches possibles.

Ø Diviser le problème :

Le projet est subdivisé en sous-‐projets portant sur le développement d'une partie du système (module). Les modules sont développés dans le cadre d’une itération. è Cycles de développement itératifs.

è Quand le problème a résoudre est très ardu, on peut essayer de diviser le système e-‐business en différents modules : un module de vente, un module de suivi de commande, un module de facturation, etc. Ensuite on développe ces modules les uns derrières les autres. On parle de cycle de développement itératif : on re-‐parcours.

Ø Résoudre le problème en plusieurs passes :

Deuxième approche pour maitriser la complexité : retravailler plusieurs fois le système ou des parties du système. Jusqu’au moment ou on obtient un système ou sous système qui donne satisfaction. Le système est construit en plusieurs passes jusqu’à être utilisable.

è Prototypage (très bien)

Ø le choix de l’approche dépend de la complexité du problème mais des coûts s’ajoutent en termes de gestion de projet



Possible de combiner ces deux approches mais il n’y a pas d’approche figée, universelle. è Adaptation en fonction des particularités etc.

ITERATION

L’application du cycle en cascade sur un module produit un délivrable testable et dure typiquement 2 à 6 semaines.

Itération : c’est le parcours de quelques phases clés è ce parcours peut être répété a chaque itération. Les itérations sont répétées un certain nombre de fois en fonction de la complexité et l’importance du système. Les premières itérations portent sur les aspects les plus risqués du système

Si je divise mon système en différents modules je vais avoir une itération par module è peuvent être répétées si on veut construire le système morceau par morceau ou le construire en plusieurs passes (parce que super compliqué)

Exemples d’activités reprises dans une itération :

-‐ analyse (étude des besoins) + conception + mise en œuvre (programmation) ou -‐ collecte des besoins + analyse + conception + mise en oeuvre + test

On répète ces phases au sein d’une itération

MAITRISE PROGRESSIVE DES RISQUES

Idée : en travaillant par itération on maitrise mieux les risques.



CYCLE ITERATIF

L’idée du cycle itératif est de ne pas développer tout le système en une fois, mais de le découper en plusieurs modules et de le livrer en plusieurs fois è développement modulaire :

• le système est décomposé en modules • les modules sont produits et testés à sein d’une itération • les modules sont intégrés progressivement dans le système final

Les itérations sont organisées en cascade et durent peu de temps, ce qui assure une certaine stabilité.

PROTOTYPAGE



DECOMPOSITION + PROTOTYPAGE

On peut combiner décomposition et prototypage et, par exemple, faire travailler des équipes en parallèle. è Exécution parallèle des itérations, etc. c’est très bien mais cela a un cout en terme de gestion de projet.



2. LANCEMENT DU PROJET

Un projet est souvent initié par les utilisateurs qui éprouvent un nouveau besoin ou qui identifient une opportunité d’affaire. Par exemple, suite à un besoin de communication en interne on lancera un projet intranet ou encore suite à l’identification d’une opportunité de vente à distance, on lancera un projet de boutique Web.

èEn général la plupart des initiatives proviennent des collaborateurs de l’entreprise qui trouvent qu’une automatisation complémentaire serait bénéfique.

Il faut vérifier si le projet réalise la vision et la stratégie de l’entreprise. Par exemple, si l’objectif stratégique de l’entreprise est la maximisation des compétences internes, un projet qui rentre dans le cadre serait celui d’un intranet sur lequel partager les connaissances.

è L’initiateur du projet va devoir le défendre devant un décideur. L’alignement stratégique est important dans ce cadre.

Qu’est ce qu’implique les taches managériales de gestion de projet ? Le lancement d’un projet implique 3 choses :

Ø cadrer le système (QUOI) è définition de la portée du système : Que veut on exactement ?

Ø identifier les ressources (QUI) è gestion des acteurs : Qui va être impliqué dans le développement à tous les niveaux ?

Ø planifier les tâches (QUAND et COMMENT) è gestion du projet è La planification des tâches va déterminer l’ordonnancement du projet

Les activités liées au lancement de projet se retrouvent dans des projets d’autre nature que projet de développement e-‐business



1. DEFINITION DE LA PORTEE DU SYSTEME E-‐BUSINESS

Objectifs :

Ø Montrer comment le projet rencontre les préoccupations de l’entreprise, comment le système réalise les objectifs stratégiques de l’organisation en fonction des contraintes

Ø Positionner le futur système dans la chaine de valeur de l’organisation On a le département vente et on estime qu’un site de vente en ligne pourrait améliorer la valeur apportée par ce département.

Ø Elaborer une description suffisante du système pour une première estimation de l’effort de développement è Imaginer le futur système (allure du futur site de vente ou autre) pour pouvoir déterminer une estimation de cout (combien cela coute et rapporte ?)

Activités :

Ø Décrire le contexte et la motivation du système (métier de l’organisation, objectifs stratégiques, etc.)

Ø Identifier les objectifs, les contraintes, les fonctions et la cible du système Ø Identifier la valeur apportée par le système

EXEMPLE : EM2

Document de cadrage de projet, on veut motiver notre idée è on va spécifier le contexte et la motivation

Contexte et motivation:

Ø un détaillant d’électroménagers, EM2, gère son service après-‐vente (SAV) manuellement et sans procédures claires. EM2 fournit peu d’informations aux clients après la vente (conseils d’utilisation, etc.)

Ø EM2 a pour objectif stratégique de fidéliser sa clientèle. Pour cela, elle souhaite augmenter la valeur de son SAV en proposant une meilleure information à sa clientèle et en coordonnant le travail de l’équipe SAV è projet de développement d’un système e-‐business pour le SAV

Ici : idée d’automatisation d’un service après vente (SAV) pour une chaine de magasin qui vend de l’électroménager.

On précise l’objectif qui est augmenter la valeur du service après vente en proposant une meilleure information a la clientèle et en coordonnant mieux le travail de l’équipe. Cette motivation s’inscrit dans un objet de l’entreprise qui pourrait être de fidéliser la clientèle. Un SAV de meilleure qualité va contribuer à rendre le client plus content (è fidélisation).



è On voit comment ce projet de développement rentre dans ces préoccupations de haut niveau de l’entreprise

Objectifs du système : Qu’est ce qu’on attend de ce système dans les grandes lignes ?

Ø informer le client après l’achat Ø formaliser la gestion des réparations

è Objectifs qui restent assez génériques mais on va les détailler

Les contraintes du projet :

Ø budget: 26000€/délais: 6mois Ø ressources internes : limitées au responsable du SAV

Après on peut passer dans une description plus détaillée de ce qu’on attend du système, ici on reste vague.

Les fonctions du système :

Ø publier les modes d’emploi des appareils vendus Ø publier des FAQ alimentés par les réparateurs Ø automatiser la planification des demandes de réparation chez le client Ø tracer les étapes des réparations en magasin

Cible :

Ø réparateur SAV Ø clients

è On veut connaitre la cible du système : ici les clients et les réparateurs du SAV sont ceux qui vont exploiter cette plateforme.

Il faut ensuite identifier des catégories de clients pour un site de vente en ligne è Clients dans la catégorie professionnelle etc. C’est important pour personnaliser le système par rapport aux segments de clientèle.

La valeur du système est attendue à 2 niveaux :

Ø client : accompagnement après l’achat, rapidité et transparence dans l’organisation des réparations

Ø réparateurs SAV : partage et centralisation de la connaissance en interne, meilleure coordination des réparations



Dans quelle mesure le système va contribuer à apporter de la valeur pour le client et l’entreprise.

Exemple : au niveau des réparateurs meilleure organisation dans la planification des réparations. è Grâce à des fiches de suivi dans les réparations.

2. GESTION DES ACTEURS

Objectifs : maximiser les chances de réussite du projet en mobilisant et en gérant les ressources les plus adaptées

Réfléchir sur les acteurs : Le projet va être pris en charge par une équipe. Même dans un projet de haute technologie, les personnes sont souvent un problème è il est crucial (Facteur Clé de Succès) de constituer une équipe compétente qui fonctionne bien. Pour ce, il y a des tâches à réaliser :

Ø identifier les compétences et rôles (lister les compétences nécessaires, elles sont multiples è Impose des profils techniques très variés)

Ø désigner les acteurs du projet et constituer une équipe (une fois les rôles à remplir listés, les assigner à des personnes disponibles)

Ø gérer l’équipe du projet (une fois l’équipe constituée il faut la gérer)

L’EQUIPE DE PROJET : UN FACTEUR CLE DU SUCCES

La dimension humaine est importante dans un projet e-‐business

Ø la technologie n'est qu'une des composantes d'un projet informatique Ø les problèmes humains sont souvent plus intenses que les problèmes techniques

Les relations humaines doivent être soigneusement gérées

Ø construire un esprit d'équipe et une relation de confiance Ø veiller à la bonne communication entre utilisateurs et informaticiens Ø gérer pro-‐activement les conflits

Le courant doit passer, l’équipe doit fonctionner etc. è La dimension humaine est vraiment cruciale. On tente de gérer pro-‐activement l’équipe, gérer les conflits, etc. Une gestion proactive des ressources humaines est tout à fait essentielle.



EQUIPE D’UN PROJET E-‐BUSINESS

Un projet e-‐business comporte de nombreuses dimensions è nombreux rôles et équipe pluridisciplinaire.

Par exemple, un site de vente doit être attractif è besoins de compétences artistiques

La particularité des développements e-‐business c’est que pour qu’un site de vente en ligne soit attractif par exemple, on a besoin de beaucoup de compétences. Des spécialistes en Base De Données, en sécurité, des ergonomes sont des besoins.

Exemple : conception de la charte graphique, design d'un site, etc.

Catégories d'acteurs :

Ø utilisateurs : spécialistes métier Ø informaticiens : spécialistes des TIC Ø experts : apport ponctuel de compétences de pointe Ø sponsor : apport du financement

ACTEURS PRINCIPAUX D’UN PROJET E-‐BUSINESS



Catégories d’acteurs qu’on retrouve dans la plupart des projets e-‐business :

Ø Utilisateurs :

Compétences : ils connaissent parfaitement leur métier. On les appelle les spécialistes du domaine d’application (métier, situation concrète pour lequel on utilise la technologie de l’information)

Ø Sponsors :

C’est celui qui libère les fonds, pas d’implication directe dans le projet, mais il donne son aval pour l’engagement de budget.

Ø Informaticiens :

Ce sont les spécialistes des technologies. On a pleins de déclinaisons : chef de projet, analyste, programmeurs, designer, ergonome, etc.

Ø Experts

Ils apportent une compétence pointue à un moment donné.

L’expert en sécurité, par exemple, s’assure du niveau de sécurité raisonnable du système. Le qualiticien est responsable qualité, c’est quelqu’un qui aide le chef de projet à gérer la qualité.

Quel peut être le niveau d’intervention d’un juriste dans un projet e-‐business ? Si on développe des sites qui collectent des données à caractère personnel par exemple, un juriste sera nécessaire. Le juriste sera également utile lors de la rédaction d’un contrat de service è par exemple dans le cas de développement IT fait en extérieur, il est important de rédiger un contrat en bonne et due forme.

CHEF DE PROJET

Le chef de projet conduit le projet

Ø Il planifie, désigne les personnes et assigne les responsabilités Ø Il surveille le déroulement et prend des mesures correctives Ø Il rapporte au management

Le chef de projet dispose de compétences managériales plutôt que techniques

Ø gestion d'équipe, coordination d’équipe Ø facultés d'écoute et de compréhension Ø esprit de décision Ø sens de l'organisation Ø autorité Ø culture générale de la technologie



EXEMPLE DE PROFILS DE CHEF DE PROJET

3. GESTION DE PROJET

Objectif: fournir un support organisationnel à la réalisation d'un projet

Tâches principales:

Ø préparer le projet o identifier et planifier les tâches du projet o assigner les ressources o déterminer les contraintes du projet

Ø suivre le projet (pendant les phases ultérieures) o contrôler l’avancement de projet et éventuellement prendre des mesures

correctives o capitaliser l’expérience

RESULTAT SOUS CONTRAINTES

Un projet doit fournir un système de qualité fixée sous contraintes.



TECHNIQUES DE PLANIFICATION

Ø Intention : planifier et synchroniser plusieurs tâches interdépendantes réalisées par des acteurs

Ø Diagramme de Gantt (1917) è présentation graphique des tâches dans un calendrier

Ø PERT : Program Evaluation and Review Technique (US-‐ Navy, 50') o présentation graphique des relations entre tâches o marge totale : intervalle de temps pendant lequel une tâche peut être

différée sans différer la date de fin du projet o chemin critique : séquence de tâches pour lesquelles une modification de

durée entraîne une modification de la durée du projet

EXEMPLE DE GANTT AVEC CHEMIN CRITIQUE



Tâches en rouge : tâches critiques è ne peuvent être rallongées ou différées sous peine de retarder l’ensemble du projet. Les tâches critiques n’ont aucune marge.

Tâches en bleu : tâches non-‐critiques è ces tâches ont une marge. Prenons le cas d’une tâche avec une marge importante, on pourra la réaliser plus loin dans le processus par exemple, sans que la date de fin du projet ne soie impactée.

EXEMPLE D’ALLOCATION

ETUDE DE CAS : SPORTS D’HIVERS



Contexte et motivation:

Ø la promotion et la prise d'inscription aux SH prennent beaucoup de temps car ces deux opérations sont complètement manuelles. Chaque année, il faut recommencer les mêmes actions sans pouvoir réutiliser les acquis des années précédentes (affichage, etc.)

Ø le cercle des étudiants s'est fixé comme objectif stratégique de soutenir davantage les étudiants en difficulté (scolaire, financière, etc.). Comme le cercle connait des problèmes de recrutement récurrents, il compte sur davantage d'automatisation pour soutenir sa stratégie et recentrer l'équipe sur des projets où les personnes ont une valeur ajoutée importante

Ø l'organisation des SH est actuellement manuelle et consomme beaucoup de main d'œuvre è lancement d'un projet de développement d’un système e-‐business pour la gestion des SH

Objectifs du système :

Ø présenter l'offre de SH du cercle Ø promouvoir l'offre de SH du cercle Ø suivre les inscriptions des étudiants participants

Les contraintes du projet :

Ø budget: 1000€/délais: 6 mois Ø ressources internes : l'équipe du cercle et, ponctuellement, le service informatique

de l'école

Les fonctions du système :

Ø présentation de l'offre o publication des informations détaillées sur le voyage (Exemple : destination,

prix, service, etc.) o publication des conditions générales / responsabilité (Exemple : modalités

de paiement, désistement, assurance, etc.) o publication du nombre de places disponibles et de la liste des inscrits

Ø promotion de l'offre

o publication électronique de l'affiche d'annonce o mailing de prospection auprès des étudiants non inscrits

Ø suivi des inscriptions des étudiants participants

o enregistrement d'une inscription o enregistrement d'un désistement o suivi des paiements o envois de mails de confirmation d'inscription et de rappel de paiement



Cible :

Ø étudiants Ø gestionnaires du voyage

La valeur du système est attendue à 2 niveaux :

Ø étudiants : o disponibilité de l'information o disponibilité de la procédure d'inscription/désistement o validation et confirmation de l'inscription

Ø gestionnaires du voyage :

o automatisation de la gestion de l'inscription o suivi centralisé et organisé des désistements et des paiements o automatisation de la communication o réutilisation du système d'année en année

Rôles et compétences :

Ø chef de projet o coordonne le projet et rapporte au sponsor o sens de l'organisation, disponibilité, maîtrise de MS-‐Project

Ø analyste/programmeur

o collecte les besoins des utilisateurs, conçoit et met en œuvre le système o maîtrise des langages de modélisation et des outils de développement

Ø représentant utilisateur

o formule les attentes des utilisateurs o expérience dans l'organisation des SH

Ø sponsor

o veille à l'alignement stratégique du projet et décide de la libération des fonds

Ø hébergeur o déploie le système dans une infrastructure WEB o compétences techniques dans la gestion de serveurs et réseaux

Equipe :

Ø chef de projet : Sophie souhaite s'investir dans le cercle et a une expérience de coordination de projets (mouvement de jeunesse)

Ø analyste/programmeur : Nabil est bachelier en informatique et adore la programmation



Ø représentant utilisateur : Magali a organisé les SH les deux années précédentes Ø sponsor : Arnaud est le président du cercle des étudiants Ø hébergeur : Eric gère l'infrastructure WEB de l'école et est prêt à héberger

gratuitement le système

Planification :

Etude de cas : sports d’hiver è Petite synthèse :

On va voir ce qu’on doit produire comme infos pour définir une première idée du projet. Ici, on est chef du projet et responsable d’un site d’inscription en ligne.

Ø 1ère étape : Lancement du projet

Essayer de motiver le projet par rapport aux intentions et objectifs stratégiques de l’entreprise (ici le cercle des étudiants)

Ø Priorité du cercle : Aider les étudiants qui ont des difficultés

Par rapport à cet objectif, on veut automatiser certaines activités du CDE pour que toute une série de taches qui étaient réalisées manuellement puissent être automatisées. On va développer une plateforme d’enregistrement en ligne pour les sports d’hivers. On voit un alignement stratégique du projet par rapport aux objectifs du cercle.

Ø Objectifs du système :

Rappel : un projet est un exercice de maximisation du résultat et de sa qualité sous contrainte (contraintes cf. slide è les plus évidentes sont celles de budget et de délai, mais il y a également des contraintes légales, etc.)



On va essayer d avoir une première description de l’équipe et du planning

On va détailler les fonctions du système, quelles sont les facilités attendues de ce système web.

Ø Cible (à préciser) : à qui s’adresse le système ? -‐ Aux étudiants -‐ Aux responsables du CDE qui gèrent le voyage

Il faut motiver la valeur qu’apporte ce système dans la chaine de valeur.

Un aspect super important des projets e-‐business est l’aspect humain. Les problèmes les plus fréquents proviennent de la gestion des personnes. De ce fait, l’identification des rôles et personnes nécessaires est préconisée. Une fois qu’on a listé les rôles et compétences associées, on peut essayer de constituer notre équipe.

Une fois qu’on a identifié les différents rôles on peut passer a la planification avec un logiciel. On part d’une série de taches interdépendantes dans le temps et planifiées.

On a assigné les différentes taches aux membres de l’équipe.

On a décomposé le système en différents modules è on fait souvent cela en informatique car le développement d’un système en un coup c'est trop compliqué, donc on le découpe en différents modules, on le découpe dans l’espace, et si certains modules sont complexes à mettre au point on applique une technique de prototypage è construction du système par itérations successives.

Ø 2eme étape : L’étude d’opportunité (voir chapitre suivant)



3. ETUDE D’OPPORTUNITE

Objectifs

-‐ prendre la décision d'engager ou non le projet (pass or fail), d’engager des fonds dans le projet en considérant :

o l'apport du projet è voir si il est supérieur aux investissements o la faisabilité du projet

Tâches

-‐ 1ère étape : réaliser une critique de l'existant pour identifier les lacunes que le futur système pourrait combler. Si il y a un système déjà existant, la première chose à faire pour motiver le nouveau projet est d’identifier les lacunes du système existant. La critique doit être constructive, l’objectif est de mettre des lacunes en évidence qu’on évitera de reproduire dans un futur système.

-‐ 2ème étape : essayer de réaliser une étude pour évaluer l'apport du futur système o calcul du retour sur investissement (ROI) o évaluation en terme de bénéfices intangibles

-‐ 3ème étape : évaluer la faisabilité face aux risques

1. RETOURS D’UN SYSTEME

RENTABILITE D’UN PROJET DE DEVELOPPEMENT

Plusieurs techniques purement financières

• ROI = bénéfices annuels / coûts annuels • valeur actuelle nette – VAN, taux de rentabilité interne – TRI, etc.



La difficulté c'est que l’évaluation d’un retour purement financier est souvent défavorable parce que souvent l’IT participe aux frais de structure, des activités, etc. C’est comme la GRH, le département IT n’a pas un apport direct au chiffre d’affaires.

è Si on utilise les techniques habituelles (le ROI par exemple) ce ne sera souvent pas un argument prédominant pour motiver le projet.

Il y a une série de bénéfices indirects ou intangibles à considérer aussi :

• les bénéfices intangibles o Exemple : amélioration de l’image de marque après un redesign d’un site

• les opportunités offertes par l'application des TIC o Exemple : apports de clients étrangers grâce à la vente en ligne

Exemple : on a une nouvelle plateforme intranet, on peut espérer a terme augmenter la compétence et productivité des collaborateurs. è Ce n’est pas mesurable purement financièrement.

On va quand même calculer un ROI, même si il est négatif mais on va compléter grâce à une argumentation qui liste tous les bénéfices intangibles ou indirects qu’on espère retirer du projet.

Ex-‐post, une fois le système déployé, on pourra vérifier après une période de mise en production, le gain en chiffre d’affaires, etc. au niveau global. è Il faut essayer d’identifier les couts pcq c'est la première chose qu’on demande : combien cela coute et combien ca rapporte.

RETOUR SUR INVESTISSEMENT : COUTS

Coûts directs è ce sont les coûts identifiables, liés directement au SI

Il faut intégrer les couts de développement et de maintenance lorsque le système est en exploitation.

• CAPEX (capital expenditure) : développement logiciel, matériel, déploiement, formation

• OPEX (operational expenditure) : maintenance, hébergement, support

cf. métrique d'évaluation d'ampleur et d'efforts.

Coûts indirects è ce sont les coûts difficilement identifiables et peu prévisibles

Exemple : correction d'erreurs, perte de productivité due à l'apprentissage d'un nouveau système, etc.



Les couts indirects sont plus délicats à évaluer. On peut s’attendre à une perte de productivité les premiers jours ou semaine de la mise en service des nouveaux systèmes parce que l’utilisateur doit se familiariser etc. è pas facile à évaluer.

RETOUR SUR INVESTISSEMENT : BENEFICES

Bénéfices tangibles è quantifiables

• réductions des coûts ou augmentation des bénéfices o Exemple : réduction du coût des transactions commerciales ou nouveau

canal de vente par Internet

Bénéfices intangibles è difficilement quantifiables

• bénéfices pour l'organisation o Exemple : meilleure communication entre les collaborateurs, meilleures

sources d'information pour la prise de décisions, meilleure ergonomie • bénéfices pour le client

o Exemple : meilleure disponibilité de l'entreprise, meilleure information sur les produits et services

è On va avoir des bénéfices chiffrables ou tangibles, par contre on va en avoir des intangibles, difficilement chiffrables, ils doivent être mentionnés mais on ne peut pas les chiffrer précisément.

Exemple : L’avantage pour un client est un bénéfice intangible

EXEMPLES D’APPORTS ATTENDUS

è Quelques arguments classiques pour motiver un projet e-‐business. Ces arguments permettent de convaincre que le projet apporte vraiment de la valeur

Améliorer l’efficience opérationnelle

• réduire les coûts de production des biens vendus o Exemple : vente de musique en ligne

• réduire les coûts de vente et d’administration o Exemple : suppression des documents papier pour les transactions

commerciales • réduire les coûts de gestion des services

o Exemple : self-‐banking



Augmenter la compétitivité

• disponibilité 7/7 et 24/24 • améliorer les interactions avec le client

o Exemple : informer et conseiller en ligne • augmenter la rapidité de la mise sur le marché

o Exemple : outil de production largement paramétrable

Améliorer la gestion des données

• augmenter la fiabilité des données • réduire les redondances • améliorer la diffusion d'information

o Exemple : intégration électronique des commandes client dans le système du fournisseur

Réduire les risques

• améliorer la surveillance de l’activité o Exemple : tableaux de bord de gestion produits de manière largement

automatisée o Exemple : état des stocks en temps réel _ moins de risque de rupture

ð Augmenter la valeur des actionnaires en profitant de l'ensemble des bénéfices apportés par le système

2. FAISABILITE D’UN PROJET

L’étude de faisabilité d’un projet est la 2ème chose à faire dans le cadre de l’étude d’opportunité. Parfois le projet n’est pas réaliste.

Ø Exemple 1 : un système de correction automatique des examens pour les professeurs, ce n’est pas réaliste, les technologies ne suivent pas.

Ø Exemple 2: se faire soigner par un robot, on n’est peut être pas encore prêt pour cela, même si on peut démontrer que cela fonctionne.



FAISABILITE FACE AU RISQUE

Le projet est faisable si les risques peuvent être raisonnablement maîtrisés.

Il est important de voir si on peut maitriser les risques, même si l’idée est bonne, etc.

è On doit montrer qu’on peut maitriser les risques liés au déroulement du projet, les risque techniques, les risques liés à la viabilité du logiciel.

Maîtriser les risques liés au déroulement du projet

Ces risques impactent le plan du projet

Ø Exemple : comment gérer une absence de longue durée d’un acteur?

Maîtriser les risques techniques

Ces risques impactent la qualité du logiciel

Ø Exemple : faible qualité d’un système de correction automatique d'examens Ø Exemple : faible performance d’un système de distribution de vidéos en ligne

Maîtriser les risques business liés à la viabilité du logiciel (à la volonté des utilisateurs de mettre le logiciel en utilisation)

Ces risques impactent la valeur attendue du logiciel

Ø Exemple : excellent système mais que personne n'utilise Ø Exemple : digitaliser toute la communication via email, forum et WiKi Ø Exemple : vote électronique (typique) : Techniquement, le vote électronique est plus

ou moins au point, il existe mais n’est toujours pas accepté pour des raisons indépendantes des 2 risques ci-‐dessus (risques techniques et risques liés au déroulement du projet) è manque d’adhésion des utilisateurs.

ARTICLE SUR LE VOTE ELECTRONIQUE

"Le vote électronique a-‐t-‐il du plomb dans l’aile ? Selon nos informations, le ministre de l’Intérieur a toutes les peines du monde à convaincre ses partenaires de poursuivre dans la voie initiée en 1991, lorsque les premières machines furent installées dans notre pays.... Aux dernières élections, le vote automatisé a concerné 44 % des électeurs, soit 100 % à Bruxelles, 22 % en Wallonie et 49 % en Flandre.

Depuis son introduction, le vote électronique n’a cessé de susciter réserves et critiques. Censé rendre le vote plus fiable, le dépouillement plus rapide et le scrutin moins onéreux, il n’a pas fait la preuve de son efficacité jusqu’ici. ... De l’aveu même du ministre de l’Intérieur, il coûte



trois fois plus cher (4,5 euros par électeur contre 1,5 pour le vote papier). Aux législatives de 2007, on a enregistré 400 incidents. Quantaugaindetemps...

«A Liège ou Bruxelles, totalement informatisés, on a eu les résultats après minuit», rappelle Michel Staszewski, de l’association Pour Eva (Pour une éthique du vote automatisé), qui milite pour un retour au vote papier, seul garant à ses yeux de transparence et de contrôle démocratique. Tel est le problème majeur, selon les détracteurs : « L’exemple est célèbre de cet élu schaerbeekois qui a obtenu plus de voix de préférence qu’il n’y avait de votants. Il y en a eu d’autres, et encore ces cas ne sont-‐ils que la partie émergée de l’iceberg, puisque sans contrôle humain, les erreurs peuvent passer inaperçues ». D’autres ont fait machine arrière. Les Pays-‐Bas, les plus avancés d’Europe, ont été contraints par la justice d’abandonner le vote électronique. Et l’Irlande y a renoncé malgré de lourds investissements”.

3. EVALUATION DU COUT D’UN SYSTEME

Par exemple, on souhaite développer un site pour gérer les sports d’hivers du CDE. Combien cela va-‐t-‐il couter ? Comment dégager un ordre de grandeur ?

Il existe un grand nombre de techniques pour estimer les couts de main d’œuvre liés au développement.

ESTIMATION DES COUTS DE DEVELOPPEMENT

But: dégager des ordres de grandeur pour décider de la faisabilité

• 1ère estimation : effort * coût moyen mensuel d’une ressource • 2ème estimation : calcul du coût de chaque tâche en fonction des ressources

affectées (cf. planification) • pour déterminer précisément les coûts, le système doit être au moins

complètement décrit

Utilisation de métriques et modèles pour :

• on va essayer d’estimer le volume du système à développer • estimer les ressources humaines à allouer au projet • dans la suite : présentation simplifiée et adaptée de la métrique des points de fonction et du modèle

COCOMO. Pour une discussion complète : Donald J. Reifer, Estimating Web Development Costs: There Are Differences, http://www.reifer.com/ ; http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html,

On saura si le système va couter 5000, 500000 ou 20000000 euros. On pourra déjà trancher sur l’opportunité du projet. Cette estimation n’est pas précise parce qu’on en est qu’à l’avant-‐projet, on n’a pas encore décrit complètement le système. Il faut aller plus loin pour



cela, par exemple avoir une idée de toutes les tâches a déployer pour faire un calcul très précis, une estimation plus précise du cout du développement.

Exemple : construction d’une maison.

Grosso modo on sait ce qu’on veut, on va faire un premier dessin avec l’architecte mais sans trop de détails. On va dégager une surface (volume du système). Par exemple : maison de 150 mètres carrés. A partir de cela, on va regarder par rapport a des projets antérieurs (par exemple) le cout moyen è règle de trois. On va obtenir un budget (ordre de grandeur, estimation).

On va d’abord estimer le volume du système puis les ressources allouées au projet.

On a besoin de deux outils : le point de fonction et les ressources à allouer au projet

Ici on va voir des versions simplifiées des modèles qu’on trouve sur le terrain. On va voir les grands principes pour voir qu’il est possible de déterminer une estimation de cout d’un système même si on n’est pas informaticien. è Objectif du cours : faciliter le dialogue entre le gestionnaire et le spécialiste.

ANALYSE PAR POINTS DE FONCTION (FP)

Principe : identifier les éléments de l'application à construire (paramètres) et les pondérer en fonction de leur complexité

Objectif : dégager une estimation a priori du volume de l'application



Ici on va essayer de décrire, projeter le futur système. On va identifier des grands composants du système. L’utilisateur doit faire une démarche pour imaginer le système auquel il pense.

Ici on va projeter le système auquel on pense en différents paramètres

-‐ les entrées : les lots d’informations rentrant dans le système. Ex : un écran de saisie, un écran pour enregistrer le descriptif du voyage, un autre pour enregistre les données de l’élève qui souhaite participer au voyage, etc.

-‐ Les sorties Exemple : rapport, facture, graphe sur écran.

-‐ Les requêtes : une extraction des données avec une certaine valeur ajoutée. -‐ Les fichiers ou tables : grappes principales de données.

Exemple : séjour, réservations, des étudiants qui veulent participer, des payments -‐ Les fichiers multimédias :

Exemple : page d accueil, page statique etc. -‐ Les composants Web réutilisables à intégrer : è importés en tant que composants

dans le système qu’on est en train de développer.

Exemple :

On doit développement un écran de login : L’écran de login est un écran avec 2 zones :

Ø le login Ø le password.

Pour un informaticien professionnel, ce n’est pas beaucoup de travail. Ce sera quelque chose de très simple à construire. Par contre, un écran de commande avec le calcul de livraison, de TVA etc., c'est plus compliqué à construire parce qu’il y a des calculs, de nombreuses zones, etc.

Dans un premier temps on va surtout se concentrer sur le principe et pas la complexité.

Chaque valeur de paramètre aura un certain poids, à calculer en fonction des différents poids et éléments identifiés, un nombre de points de fonction, unité qui représente l’ampleur du système.



EXEMPLE

Ici on a, par exemple, un écran de saisie client, c’est simple. Un écran de saisie de facture, ou de saisie produit c’est déjà plus compliqué, plus élaboré.

Ici on a une valeur abstraite de 106 points de fonction. Avec cela on n’est pas très avancé. Ca représente un certain nombre de points de fonction mais qu’est ce que ca représente en terme d’hommes/mois au niveau du développement?

PARAMETRES

• la liste des paramètres peut évoluer è La liste des paramètres n’est pas figée, il y a des variations des points de fonction. è autres paramètres possibles: communication inter-‐systèmes, intégration de composants, données à récupérer, etc. è Cela peut aussi mobiliser de l’énergie des développeurs et donc faut les considérer. Ici ce sont des exemples parmi d’autres.

• un besoin d’un utilisateur peut conduire à plusieurs valeurs de paramètres

o Exemple : une facture peut nécessiter un travail de mise en forme important et la construction d’une requête complexe. Si je demande au développeur d’écrire un système qui va me permettre d’encoder des factures =>… les données enregistrées a travers écran vont devoir être enregistré dans des tables (2eme paramètre) et il y aura peut être une sortie…

• des corrélations peuvent exister dans l’évaluation des paramètres (souvent il y a des corrélation au niveau des points de fonction, des paramètres, et souvent on retrouve ces paramètres)

o Exemple : une table a souvent un équivalent écran de saisie



EXEMPLE D’UNITES DE PARAMETRES

Ici on va voir quelques indications qui permettent dévaluer la difficulté de tel ou tel écran.

• entrée : écran de saisie è permet de créer de l’information, de l’éditer

o évaluation de la complexité : § nombre de zones de saisie/affichage – nombre de zones qui doivent

être saisies par l’utilisateur. Si j’ai juste un nom d’utilisateur et un mot de passe, ce n’est pas un écran qui va demander beaucoup de travail de programmation. Un écran avec beaucoup de zones calculées contribue à la complexité de l’écran (ex : calcul du total d’une facture ou autre).

§ importance des contrôles de validité des données. § importance de l’automatisme dans la saisie (remplissage

automatique, proposition de données à l’utilisateur, etc.) o unité alternative : messages digitaux en provenance d’autres systèmes

• sortie : rapport à imprimer è si on doit programmer des rapports papier ou écran avec beaucoup de calculs différents, ou graphiques, alors cela représente beaucoup de travail, et cela fait monter la complexité du rapport.

o évaluation de la complexité : § difficulté de la mise en page § variété de l’information à représenter § construction de graphiques

o unité alternative : messages digitaux à envoyer vers d’autres systèmes

• requête : interrogation d’une base de données è il y a des requêtes plus simples que d’autres et parfois une requête peut impliquer plusieurs requêtes successives.

o évaluation de la complexité : § nombre de tables et de champs à accéder § importance des calculs à réaliser (agrégation, etc.)

o unité alternative : outil de recherche textuelle

• table ou fichier : table d’une base de données relationnelle o évaluation de la complexité :

§ nombre de champs – nombre de colonnes § importance des contraintes



• fichier multimédia : conception d’un page Web type è un peu comme les écrans de saisie, le nombre de zones à indiquer à l’écran induit une lourdeur.

o évaluation de la complexité : § nombre d’éléments d’information à présenter § difficulté de la mise en forme

Exemple : une page d'accueil avec des menus est plutôt complexe – il y a des modules qu’on intègre, c'est toujours complexe Exemple : une page avec des graphiques est plutôt de difficulté moyenne

• composant Web à intégrer o évaluation de la complexité :

§ complexité de paramétrage du composant § interactions avec le site Web -‐ interaction entre les composants

Exemple : passage de paramètre vers un module de paiement est plutôt complexe Exemple : saisie d'information par le composants (News, forum, etc.) est plutôt complexe

EXEMPLES DE COMPOSANTS WEB



CONVERSION EN LIGNES DE CODE

Ce modèle n’a pas des points de fonction comme entrée mais bien un certain nombre de lignes de code. è 35 lignes de code en Access.

è 106 points de fonction, développés avec le langage java par exemple, on va faire 106 x 63 et on va arriver a un nombre de lignes de code. Il y a rien de plus qu’une simple conversion d’unité là derrière.

Une fois qu’on a ca, on peut appliquer des métriques d’estimation d’effort.

ESTIMATION DE L’EFFORT DE DEVELOPPEMENT



L’effort exprimé en mois homme est proportionnel a des milliers de lignes de code avec un exposant c relativement proche de 1 (a & b sont des constantes)

Cf. graphe : évolution de l’effort en fonction de la taille è Légèrement exponentiel et non linéaire pcq gérer complexité gros systèmes.

Il y a des facteurs qui sont ici multiplicatifs qui sont des facteurs d’ajustement qui tiennent compte de propriétés générales du système et son environnement.

COCOMO : CONSTRUCTIVE COST MODEL SIMPLIFIE

Modèle d’estimation d’effort : COCOMO (un modèle parmi d’autres)

Ø Effort – durée – nombre de ressources à affecter au projet Ø Série de constantes : a ; b, c, d

Ici : hypothèse d’un projet organique simple et maitrisé

Légère exponentielle du nombre de lignes de code

On a les formules, on les applique (on va le faire dans des exemples ici)



EFFORT ADJUSTEMENT FACTORS – EAF (EXEMPLES)

Premièrement : exemples de facteurs d’ajustement qui sont ici multiplicatifs !

è Qualité de l’équipe IT : impact très fort sur le temps de développement et l’effort de développe

• Pénalité de 46% pour des mauvais • Gain de près de 30% pour des gens très compétents.

EXEMPLES D’APPLICATION

Ø Programme organique de 32 KLOC : o E = 2,4 x 321,05= 91 hommes-‐mois o D = 2,5 x 910,38 = 14 mois o N = !"

!" = 6,5 hommes

Imaginons qu’on veut développer un programme organique pour une PME. On arrive vite a 32000 lignes de code si on applique la technique des points de fonction (FP) ce qui va nous donner un effort de 91 homme mois.

Si on connaît le salaire moyen d’un informaticien, on le multiplie par le nombre d’homme-‐mois et on a une première estimation du budget.

Si on fait appel à un informaticien extérieur, combien cela va-‐t-‐il nous couter ? Tarif journalier ?

Il travaille 8h, ca va couter environ 400-‐600 euros par jour.



è On va nous facturer un chef de projet jusque 800 à 900 euros par jour et pour des spécialistes pointus, réputés, ca peut monter à 2000 ou 3000 euros par jour + les frais genre hébergement etc. (Carrière informatique = assez rémunératrice).

Ø Claroline : 460 KLOC o E = 1500 hommes-‐mois o D = 40 mois o N = 37 hommes

Ø Développement d’un OS de 35 millions de lignes è Système d’exploitation (OS) qui fait 35 millions de lignes de code.

o E = 1.021.372 hommes-‐mois o D = 210 mois = +/-‐ 17 ans o N = 4878 hommes

Effort de plus de 1 million d’homme-‐mois = 17 ans de travail pour 5000 personnes pour 1 seul système d’exploitation, c'est énorme… è Par exemple, chez SAP, l’équipe de développement est d’environ 8000 personnes et ils existent depuis plus de 25 ans.

Chiffres concernant les équipes affectées par Microsoft tous des versions antérieurs des Windows :

Exemple : pour le développement, faire évoluer, Windows XP à Windows server 2003 : 4400 personnes pour produire 50 millions de lignes de code. Windows existe depuis plus de 20 ans et a été conçu à partir de systèmes plus anciens … ces ordres de grandeurs ne sont donc pas si délirant que ca. Très difficile de trouver des chiffres…

Ø Productivité implicite du modèle : 16 LOC par jour par personne

Si on calcule la productivité implicite de ce modèle, par exemple : 32000 lignes de code, on divise ca par 91 x 20 (on fait travailler nos personnes 20 jours par mois) on arrive a une productivité d’environ 16 lignes de code par jour, c'est faisable, même confortable de produire 16 lignes de code par jour, mais pas réaliste, les efforts dont on parle incluent la programmation mais aussi la gestion de projet etc. tout rentre en ligne de compte dans l effort de travail, on ne fait pas que programmer.



EXEMPLES D’APPLICATION : WINDOWS NT

EXERCICE: MAXIMAT

Enoncé :



Solution :



EXERCICE : CUISIGROS

• L'entreprise de restauration industrielle Cuisigros souhaite informatiser le suivi de son activité avec une application web greffée à son Intranet.

• L'intranet affichera des informations utiles pour les employés, à savoir : une page dédiée à l'organigramme, une page dédiée aux consignes à respecter sur le lieu de travail, et une page d'accueil reprenant un module de news, un module météo et le menu revoyant aux pages de l'intranet et aux fonctions de l'application de suivi.

• L'entreprise prépare des repas qu'elle livre à des entreprises de plusieurs zonings industriels. Elle compte une centaine de clients et livre près de 2500 repas par jour. Les repas sont essentiellement livrés le midi, mais Cuisigros organise également des réceptions en soirée, ce qui implique des prestations supplémentaires de son personnel.

• L'application à développer doit supporter les concepts suivants: • les fournisseurs et les commandes fournisseur. Les informations à gérer sur les

fournisseurs sont assez traditionnelles et nécessitent un écran d'encodage assez simple. Le système doit proposer à l'écran une liste de commandes fournisseur basée sur les repas à préparer; cette liste est confirmée par un opérateur. Les bons de commande doivent être envoyés électroniquement, bien que cela soit potentiellement compliqué vu la diversité des systèmes informatiques des fournisseurs;

• les clients et les commandes client. La structure de la clientèle de Cuisigros est complexe: le système doit gérer plusieurs catégories de clients et maintenir de nombreuses données, comme les habitudes alimentaires et culturelles. Par contre, les commandes client sont très classiques et comportent en moyenne 15 lignes articles (menus et boissons);

• les matières premières et leur stockage. La gestion des matières premières consiste simplement à maintenir un descriptif de base, des quantités en stocks, des dates de péremption et des mouvements entrants et sortants. Des inventaires réguliers doivent être imprimés.

• les produits finis. Cuisigros gère un petit nombre de produit finis (correspondant à des menus type) mais leur description est relativement complexe: elle inclut la composition d'un menu, i.e., ses différentes matières premières et leurs quantités respectives, une tarification par quantité et des recommandations de fabrication. L'expédition, elle, n'est pas automatisée;

• le planning de production. Il est établi chaque semaine en fonction des commandes client. Cette partie de l'application est la plus complexe, puisqu'il faut anticiper les commandes fournisseurs et préparer l'horaire des employés. La réalisation du planning inclut l'édition (1) d'horaires de travail pour les employés, (2) d'un tableau de production et (3) d'une liste de propositions de commandes fournisseur;

• les employés et le suivi des prestations. Le système gère des données de base concernant les employés et enregistre les prestations de chacun en distinguant les heures régulières des heures supplémentaires. Un listing de comparaison entre les horaires de travail issus du planning de production et les prestations réelles est à édité chaque fin de mois. Un récapitulatif des toutes les prestations est envoyé chaque semaine à un secrétariat social pour préparer le calcul des salaires.



SOLUTIONS

1. Analyse de l’énoncé :

Enoncé Points de fonction L'intranet affichera des informations utiles pour les employés, à savoir : une page dédiée à l'organigramme, une page dédiée aux consignes à respecter sur le lieu de travail, et une page d'accueil reprenant un module de news, un module météo et le menu revoyant aux pages de l'intranet et aux fonctions de l'application de suivi.

è page organigramme (fichier multimédia moyen car graphique) è page consignes (fichier multimédia simple) è page d'accueil (fichier multimédia difficile car menu et modules) è module de news (composant moyen car saisie de données) è module météo (composant simple)

Les informations à gérer sur les fournisseurs sont assez traditionnelles et nécessitent un écran d'encodage assez simple

è saisie fournisseur (entrée simple – rien n'indique du cet écran soit particulièrement difficile à construire) è table fournisseur (table simple – les données saisie à l'écran doivent être enregistrées dans une structure de stockage)

Le système doit proposer à l'écran une liste de commandes fournisseur basée sur les repas à préparer; cette liste est confirmée par un opérateur.

è saisie commande fournisseur (entrée difficile – entrée car l'opérateur doit alimenter le système en données par sa confirmation, difficile car un travail de calcul de la liste des commandes fournisseurs doit être réalisé) Alternative : requête moyenne ou difficile pour calculer la liste des commandes fournisseur + écran de confirmation simple è table commande fournisseur (table simple – les données saisies à l'écran doivent être enregistrées dans une structure de stockage) è table repas (non prise en compte car correspond à un produit fini plus loin dans l'énoncé)

Les bons de commande doivent être envoyés électroniquement, bien que cela soit potentiellement compliqué vu la diversité des systèmes informatiques des fournisseurs

è bon de commande fournisseur (sortie difficile -‐ travail technique d'envois de messages digitaux vers des systèmes différents)

La structure de la clientèle de Cuisigros est complexe : le système doit gérer plusieurs catégories de clients et maintenir de nombreuses données, comme les habitudes alimentaires et culturelles.

saisie client (entrée difficile) �table client (table difficile)



Par contre, les commandes client sont très classiques et comportent en moyenne 15 lignes articles (menus et boissons)

è saisie commande client (entrée moyenne – nombre de données à enregistrer relativement important, calculs à réaliser, comme le total de la commande) è table commande client (table simple)

La gestion des matières premières consiste simplement à maintenir un descriptif de base, des quantités en stocks, des dates de péremption et des mouvements entrants et sortants.

è saisie matière première et stock (entrée moyenne) è table matière première (table simple) è table mouvement de stock (table simple)

Des inventaires réguliers doivent être imprimés. è listing d'inventaire (sortie simple) Cuisigros gère un petit nombre de produit finis (correspondant à des menus types) mais leur description est relativement complexe : elle inclut la composition d'un menu, i.e., ses différentes matières premières et leurs quantités respectives, une tarification par quantité et des recommandations de fabrication. L'expédition, elle, n'est pas automatisée

è saisie produit fini (entrée difficile – beaucoup de données à saisir) è table produit fini (table difficile)

Le planning de production. Il est établi chaque semaine en fonction des commandes client. Cette partie de l'application est la plus complexe, puisqu'il faut anticiper les commandes fournisseurs et préparer l'horaire des employés. La réalisation du planning inclut l'édition (1) d'horaires de travail pour les employés, (2) d'un tableau de production et (3) d'une liste de propositions de commandes fournisseur;

è listing d'horaire de travail (sortie difficile – si on suppose une mise en forme graphique comme un calendrier de travail) è requête horaire de travail (requête difficile – le calcul de l'horaire dépend des commandes client et devrait demander des calculs élaborés) è table horaire de travail (table simple – on suppose que les données sur les horaires doivent être mémorisées après calcul) è listing tableau de production (sortie simple) è requête tableau de production (requête difficile – le calcul dépend des commandes client et devrait demander des calculs élaborés) è table production (table simple – on suppose que les données sur les horaires doivent être mémorisées après calcul) è listing proposition de commandes fournisseur (sortie simple – le calcul des propositions est déjà valorisé dans l'écran de saisie des commandes fournisseur)

Le système gère des données de base concernant les employés et enregistre les prestations de chacun en distinguant les heures régulières des heures supplémentaires.

è saisie employé (entrée simple) è table employé (table simple) è saisie prestation (entrée simple) è table prestation (table simple)

Un listing de comparaison entre les horaires de travail issus du planning de production et les prestations réelles est à édité chaque fin de mois.

è listing de comparaison (sortie moyenne)

Un récapitulatif des toutes les prestations est envoyé chaque semaine à un secrétariat social pour préparer le calcul des salaires

è Listing récapitulatif des prestations (sortie moyenne)



2. Estimations chiffrées :

Estimation d’effort = un exercice possible a l’examen. Comment peut on évaluer le cout de développement d’un système e-‐business et l’évolution métrique. Il ne faut pas connaître les formules par cœur, elles seront fournies à l’examen si on en a besoin. Cas d’application qui pourrait nous être demandé.



4. SPECIFICATIONS

1. DEFINITION DE LA SPECIFICATION

Objectif

Ø établir une première spécification du système à construire sous un angle fonctionnel, i.e., indépendamment de choix technologiques

Ø décrire le «quoi» et non le «comment»

Tâches

Ø rassembler les besoins détaillés des utilisateurs du système à construire en termes d'informations, de traitements d'informations et d’interfaces

Ø sur base des besoins exprimés par les utilisateurs, décrire les structures de données, les traitements, le contrôle et l’interface du système

Ø produire un document de spécifications fonctionnelles détaillé

Formalisme: langages de modélisation graphique

1ère question : « Qu'est ce qu’on veut exactement ? » L’objectif est de spécifier le futur système qu’on veut.

Tâches : Attention la phase de spécification est une phase fonctionnelle, on ne s’intéresse pas à la mécanique. Ici on va décrire le système comme une boite noire et identifier les fonctionnalités. Autrement dit, on décrit ce que le système va faire et pas comment il va rendre ses services. On va demander au programmeur un écran qui permet d’enregistrer les commandes mais on ne va pas lui imposer une manière de le faire.



Objectif : comprendre les besoins des utilisateurs et, sur base de ces besoins, décrire le système sous différentes dimensions.

A l’issue de cette phase de spécification on va écrire un document fonctionnel qui décrit toutes les attentes des utilisateurs et qui peut servir de cahier de charge. On va l’envoyer à des prestataires IP potentiels (expliqué dans le docu sur IC)

Si on délègue le développement à l’extérieur, tout ce qui est dans le cahier de charges revêt une allure contractuelle. è Enjeu vraiment important !!!

Formalisme : plusieurs possibilités mais on utilise beaucoup des techniques graphiques pour représenter les besoins de l’utilisateur (diagramme de cas d’utilisation, etc.)

DIMENSIONS CONSTITUTIVES

Très important è Fait le lien entre les besoins et les spécifications. En général les deux sont très corrélés !

Exemple: on peut dire « j’ai besoin d'un système de facturation en ligne » et donc au niveau des spécifications je pourrais dire « j'ai besoin d'un système qui permet d’enregistrer une facture, de la diffuser et d’enregistrer son paiement ».



TYPES DE BESOINS

Quels sont les types de besoins pour les applications e-‐business ?

Besoins informationnels è site vitrine

Ø recouvrent les informations à publier Ø identification du contenu, définition de la politique de mise à jour, etc.

Exemple : présentation de l'entreprise, catalogue de produits, etc.

Quand on développe des parties de sites vitrine (site web relativement simple sans beaucoup de manipulations de données) on va avoir des besoins informationnels.

Au départ internet est un système de diffusion d’information, de contenu, on va l’utiliser pour diffuser des infos sur notre entreprise, etc. ce sont des infos peu changeantes avec une dimension informationnelle forte.

Besoins applicatifs è application Web

Ø couvrent les traitements à réaliser par l'application e-‐business Exemple: créer une commande, passer des ordres bancaires, etc.

Ø décrits par les langages de modélisation (cas d'utilisation, etc.)

Aujourd'hui, il y a de plus en plus de manipulation de données è besoins applicatifs avec des appli qui permettent par ex a un client dune banque de créer des données, par exemple, des ordres de virement. La on est plus dans l’applicatif : la modification de traitement de donnée.

Besoins non fonctionnels

Ø couvrent des propriétés périphériques au traitement de l'information Exemple : visuel et ergonomie, performance, confidentialité des données

On va devoir aussi considérer les besoins non fonctionnels : relatifs a des caractéristiques globales de l’application pas directement en lien avec le traitement des données mais décrivent des accès globaux comme l’ergonomie, la performance et la confidentialité des données par exemple.

TYPES DE SPECIFICATIONS

On va décrire un système sous différents angles è quelque chose d'assez particulier. Si on veut rédiger les plans d’une future maison, avec une seule feuille, un modèle on a assez. Mais quand on veut spécifier les systèmes d'information c'est tellement complexe qu’il faut plusieurs angles pour comprendre è il faut plusieurs modèles, points de vue qui se complètent.



Dimensions sous lesquelles on va décrire le futur système :

Ø Structures

Quels sont les types de données que le système doit gérer ? Quelles sont les structures de données que le système doit prendre en charge ? Quand on a identifié les structures on doit encore examiner d’autres choses

Ø Traitements

è Décrire les manipulations qui vont avoir lieu sur ces structures de données.

Quelles sont les opérations à réaliser sur ces types de données ?

Ces traitements ont lieu dans un certain ordre. On ne peut pas valider une commande si on n’a pas d’abord validé un client ou tous les articles…

Ø Dynamique

Quelles sont les séquences d’opérations permises au cours du temps? Quels sont les événements qui déclenchent ces séquences?

La dynamique du système décrit la manière dont le système se comporte au cours du temps.

Ø Interfaces

Quelles est la forme et l’organisation de l’interface homme-‐machine? Quelle est l’allure des écrans qu’on souhaite pour notre site web ? Aussi un travail à faire en terme de spécification.

è Toutes les dimensions sont complémentaires et intégrées

EXEMPLES

Ø Structures

Client, commande et articles è Au niveau des structures on va préparer une base de données avec au minimum clients, commandes et articles

Ø Traitements

Créer un compte client, modifier un compte client, saisir un article, créer une commande, etc. è un processus d'enregistrement de nouvelles commande comportera 3 étapes qu’on va spécifier.

Ø Dynamique

Passer une nouvelle commande =

1. créer une compte client ou choisir un compte existant 2. choisir les articles et les quantités commandées 3. calculer les frais de livraison et le total de la commande



Ø Interfaces

Lay-‐out design d’un écran de commande è On peut déjà donner au programmeur une idée du lay-‐out général d’un écran de commande.

UML ET RUP

Au niveau des formalismes, les diagrammes de cas d’activité ou de cas d’utilisation, par exemple, sont en fait des techniques intégrées dans ce qu’on appelle une famille de langage de modélisation.

UML (Unified Modeling Language)

Ø ensemble de notations standardisées par l'OMG (Object Management Group, http://www.omg.org)

Ø techniques de modélisation graphiques Ø cf. http://www.uml.org

RUP (Rational Unified Process)

Ø processus de développement cohérent avec UML Ø ne fait pas l'objet d'une standardisation

UML et RUP : produits IBM

Ø soutenu pas de nombreux CASE Exemple : http://www-‐01.ibm.com/software/rational/uml Exemple : http://www.visual-‐paradigm.com Exemple : Open Source: http://www.staruml.com

UML reprend les standards de notifications aujourd’hui très largement utilisés par les professionnels de l’informatique. Les concepteurs d’UML ont développé un processus de développement (voir article sur IC). Au départ l’ULM et le RUP ont été développés par une société de service et cette société a été rachetée par IBM => IBM gère ces 2 technologies.



HISTORIQUE D’UML

UML a été développe par 3 gourous de l’informatique des années 90. Idée de départ : rassembler une série de techniques existantes dans un ensemble cohérent et dans un contexte commercial (intention d’universalité). è Premier terme : Unified Modeling Language

La première version date de 1995, depuis ca a bien évolué, ca a été nourri de beaucoup d’autres technologies de modélisation et aujourd’hui on en est à la version 2.5.



COMPOSANTS D’UML

On retrouve beaucoup de composants très différents. Ces composants permettent de décrire les différents aspects d'un système. On trouve aussi des diagrammes qui décrivent le système à ses différentes étapes de maturation. On s’intéresse au diagramme de cas d’activité de cas d’utilisation ms il y en a plein d’autre…

2. DIAGRAMME DE CAS D’UTILISATION

CAS D’UTILISATION : EXEMPLE INTRODUCTIF

Rappel : Objectif = déterminer les grandes fonction du système a construire.



Exemple : on veut créer une nouvelle génération de Smartphones que veut on prévoir ? Chaque grande fonction va être décrite par un cas d’utilisation.

4 types d’utilisations prévus pour le futur système :

-‐ téléphoner -‐ envoyer des SMS -‐ gérer un agenda -‐ prendre des photos

è Elles vont être détaillées

L’idée d'un cas d'utilisation c'est de décrire le comportement du système du point de vue de l’utilisateur.

Après l’étude d’opportunité, on décide d’engager le projet (ou non). Il va s’agir de décrire le système de manière relativement détaillée pour expliquer aux informaticiens ce qu’ils doivent produire.

Les utilisateurs, les personnes qui connaissent le business, les besoins etc. peuvent décrire ce système. Ce ne sont pas les informaticiens qui doivent faire ca.

CAS D’UTILISATION

Description du comportement du système du point de vue de l'utilisateur

Ø décrit le comportement du système dans son ensemble (boite noire) Ø le comportement est détaillé sous la forme de séquences d'actions exécutées par le

système suite à des stimulations extérieures Ø certaines interactions peuvent ne pas concerner directement le système, mais sont

mentionnées pour la bonne compréhension de l'utilisation du système

Les cas sont regroupés dans un diagramme de cas d'utilisation

Ø représentation des besoins ET spécification du système Ø description d'un processus business ET du système à construire Ø les cas d'utilisation servent à partitionner et structurer les besoins



Ø Premier formalisme : celui des cas d’utilisation (Use Case)

Il s’agit d’identifier les grandes fonctionnalités du système. C’est un formalisme assez simple intervenant dans les toutes premières étapes de la spécification. On essaye de cerner le système et de voir à quoi il va servir.

è Pour décrire le système on va identifier les grandes fonctions avec le concept de cas d’utilisation.

Un cas d’utilisation se représente par un ovale et cela représente une utilisation du système (vu comme la boite noire). On va identifier à quoi sert le système.

Exemple : GSM de toute première génération : On a au moins les fonctionnalités suivantes :

Ø appeler un correspondant, Ø rédiger un SMS, Ø lire un SMS, Ø répondre à un appel.

ACTEUR

Le système est vu comme une boite noire qui interagit avec son environnement.

Un acteur c'est un utilisateur ou un système a l'extérieur du système et qui « utilise » le système. Ce n’est pas spécialement une personne, ca peut être un autre système. Un acteur est extérieur au système et donc quand on décrit le fonctionnement, on indique la limite du système et on spécifie les acteurs qui interagissent avec le système et la connexion entre un acteur et un cas d’utilisation. C'est une connexion appelé « utilise ».

Représente un rôle joué par une entité qui interagit avec le système

Ø stimule le système en vue de l'exécution d'un traitement Ø envoie et/ou reçoit de l'information vers/du système



Exemple : internaute, machine, un autre SI Exemple : une même personne peut assumer plusieurs rôles, comme utilisateur et administrateur

Est extérieur au système et donc situé dans son environnement

L’acteur utilise le système (use case)

Pour décomposer l'étude de gros systèmes, on distingue :

Ø acteur clé : impliqué dans les fonctions clés du système Ø acteur accessoire : impliqué dans des utilisations "accessoires" et souvent

ponctuelles (Exemple : responsable de la maintenance)

HIERARCHIE D’ACTEURS

Peut être repris dans des structures de généralisation/spécialisation

Ø un acteur spécialisé hérite de toutes les propriétés de l'acteur qui le généralise Ø un acteur spécialisé possède des propriétés spécifiques (non héritées)

Exemple : un client est aussi un internaute et peut donc utiliser le système pour consulter le catalogue

Les acteurs interagissent avec le système. Le système répond à l’acteur en réalisant une action ou en renvoyant une information.



On verra qu’on décrira la manière dont un acteur échange dans un dialogue bien déterminé des informations et des ordres a travers un dialogue « in out ». La on identifie les facilités du système.

Dans les utilisateurs on peut avoir des sous catégories. On peut spécialiser les acteurs.

STRUCTURATION DES CAS D’UTILISATION

Un cas peut factoriser un comportement qui se répète dans plusieurs autres cas

Ø Relation utilise (include) Un cas fait toujours appel à un autre cas Exemple: le cas saisir une commande utilise le cas identification du client

Ø Relation étend avec condition (extend) Un cas fait appel à un autre cas uniquement si une condition est vérifiée Exemple: le cas confirmer la commande étend le cas calcul de devis si un devis est accepté

Les cas d'utilisation peuvent être spécialisés (pour mention)

Quand j’appelle un correspondant ou quand je rédige un SMS, dans ces deux utilisations je dois choisir un destinataire à un moment donné. Je vais regarder dans mon répertoire OU encoder un numéro qui n’est pas dans le répertoire.

Dans différentes utilisations du système on va avoir des comportements qu’on retrouve dans des cas différents. Si on veut décrire en détail chacun des comportements on va devoir décrire …

Si ce contact qu’on veut appeler ou SMSer n’existe pas dans le système on va devoir entrer le numéro. On peut extraire, factoriser, avec un cas supplémentaire : « choisir le correspondant » alors on peut connecter les cas d’utilisation entre eux par une relation qui



s’appelle « include ». Include ca signifie donc qu’à un moment donné, un cas en cours d’utilisation va brancher systématiquement vers un autre cas è c'est un premier mécanisme de structuration des cas d’utilisation. Cela allège la description du système.

Imaginons qu’on parcoure le répertoire et qu’on ne trouve pas le correspondant qui nous intéresse. Si une certaine condition est vérifiée (correspondant existe pas), on va devoir encoder un nouveau correspondant. A ce moment la cet appel est facultatif, lié a la vérification d’une condition è on parle alors d’une relation « extend» è pas systématique, on passe pas toujours par ce cas la. C’est la différence avec include.

Identifier un cas n’est pas suffisant, l’informaticien doit savoir comment le système doit se comporter dans certains cas précis. C'est un niveau de détail supplémentaire. D’abord on commence avec un niveau de détail faible puis on enrichit, jusqu’à obtenir le produit fini.

SYNTHESE DES NOTATIONS



EXEMPLE

DETAILS D’UN CAS D’UTILISATION

Ø Première description à partir de rubriques standard. Ø Détail des interactions avec des séquences d'événements.

En informatique, quand on veut construire quelque chose, on le fait rarement en une seule étape. Souvent on a une approche itérative ou on complète progressivement le travail par repasses successives. Aller directement dans le détail de tout n'est pas pertinent.

On ne va pas directement détailler toutes les fonctionnalités parce que certaines ne sont soit pas directement utiles pour la communauté des utilisateurs, soit trop complexes et couteuses. On va d’abord se mettre d’accord sur ce qu’on veut avant daller dans le détail.

On va avoir plusieurs niveaux de détails :

1. Premier niveau de détail : Compléter le nom du cas d’utilisation avec quelques rubriques standard.

Exemple : cas de recherche d’ouvrage dans la bibliothèque (è nom du cas), derrière ca on va préciser l’objectif et décrire le fonctionnement du système en quelques lignes. L’idée n’est pas de rentrer dans la description exhaustive mais de donner une première idée du



fonctionnement. C’est une description très simple (voir ci-‐dessous) et abordable pour les utilisateurs.

Rubriques :

Ø Nom du cas: recherche d'ouvrages dans la bibliothèque Ø Acteurs: lecteur Ø Objectif: sélectionner des ouvrages dans le catalogue sur base

de critères de recherche Ø Description: Un lecteur introduit des critères de recherche,

comme un mot dans le titre ou un auteur, puis le système lui présente les ouvrages correspondants et les nouveautés.

2. Deuxième niveau de détail : séquences d’évènements.

Dans un second temps on va concevoir les interactions entre le système et son environnement à travers des séquences déventement.

Ø Séquences de stimuli de l'acteur et de réponses du système Ø Séquences alternatives

o Branchement vers une séquence parmi plusieurs en fonction du résultat d'un test

Ø Séquences conditionnelles o exécution d'une séquence uniquement si une condition est satisfaite

èLes séquences alternatives et conditionnelles "complètent" la séquence standard d'un cas d'utilisation

Le système est une boite noire vers laquelle l’acteur envoie des signaux et en réponse à ces signaux le système va réagir et renvoyer un signal vers l’acteur. On cherche les étapes du dialogue entre le système et son environnement au cours du temps.



EXEMPLE DE SEQUENCE D’EVENEMENT : RECHERCHE D’OUVRAGES DANS UNE BIBLIOTHEQUE

On a 2 colonnes dans la description :

Ø Colonne gauche : actions ou signaux envoyés par l’acteur vers le système Ø Colonne droite : réponse du système

On regarde comment les évènements entrants et sortants sont organisés.

En général, on commence par décrire la séquence d’évènements standard ou tout se passe sans problème ET PUIS on réfléchit à d’éventuels problèmes. On peut compléter la liste d'évènements avec des séquences alternatives (branchement soit à gauche soit à droite) ou conditionnelles (avec une condition).

Exemple : alternative 4’ : si aucun ouvrage trouvé, alors on part dans un scénario d’utilisation différente du système. Si aucun ouvrage trouvé le système réaffiche l’écran de recherche avec un message.



EVALUATION DES CAS D’UTILISATION

Technique simple

Ø peu d'apprentissage de la part des utilisateurs

Vue abstraite du système

Ø pas de considération technique Ø centré sur le "quoi" et le point de vue utilisateur

Permet une découpe des fonctionnalités

Ø facilite la gestion du projet (itérations prioritaires, etc.) Ø première description permettant d'évaluer la charge de développement

Description informelle des besoins

Ø faiblesses du langage naturel (interprétation, ambiguïté, etc.) Ø difficulté d'évaluer la qualité des spécifications (complétude, non redondance, etc.)

è recours à d'autres langages plus formels

DEMARCHE DE CONSTRUCTION

Principes de base :

Ø construction progressive du diagramme de cas en plusieurs itérations Ø une itération complète le diagramme courant ou le détaille

Voici un exemple de méthode qui permet la construction progressive d'un cas d’utilisation :

Attention, Il faut travailler itérativement et progressivement è Ne pas vouloir tout faire en même temps.

1. Identifier les acteurs clés è ceux qui sont les principales cibles du système. Exemple : si on développe un système de vente en ligne, l’acteur principal auquel on pense c'est le client. Par rapport a ces acteurs il y en a peut être qui utilisent moins souvent le système : acteurs accessoires (point 3)

2. Identifier les cas des acteurs clés et les décrire selon les rubriques standard è Se concentrer sur le core business et les cas correspondants, avec une première description des cas des acteurs clés selon les rubriques standards.



3. Identifier les acteurs accessoires 4. Identifier les cas des acteurs accessoires et les décrire selon les rubriques standard

5. Détailler les cas avec les séquences standard d’évènements 6. Détailler les séquences alternatives et conditionnelles 7. Structurer les cas d’utilisation en factorisant les comportements communs

è On va trouver des choses communes dans différents cas et après avoir détaillé toutes les séquences possibles on va pouvoir rassembler des comportements communs. Exemple : Quand on a été dans le détail on va se rendre compte que, par exemple, la procédure d’utilisation se retrouve dans le cas d’utilisation « passer une commande » mais aussi dans le cas d'utilisation « suivre une commande ».

GRANULARITE DES CAS D’UTILISATION

Quelle ampleur pour la fonctionnalité décrite par un cas?

Cas d'utilisation trop détaillés :

Ø séquences d'événements très réduites Ø trop de cas à gérer

Cas d'utilisation trop larges :

Ø séquences d'événements interminables Ø modularisation du développement difficile



La granularité idéale doit produire :

Ø des séquences d'événements raisonnables Ø des cas correspondant à une itération du cycle de développement

EXEMPLE : ENONCE SIMPLIFIE

Ø Un magasin de vente d'articles pour animaux vend de la nourriture et des accessoires à des clients privés ou professionnels. Deux modes de vente sont proposés : une vente au comptoir et une commande Web pour les professionnels uniquement.

Ø Les magasiniers se chargent de la préparation des commandes et de la facturation. Ils réassortent le stock et tiennent la caisse.

Ø De temps en temps, des délégués commerciaux viennent en magasin pour organiser les rayons.

1. identifier les acteurs clés

Acteurs principaux :

Ø Client (sous catégorie professionnel) Ø Au niveau des acteurs de l’entreprise on a le magasinier spécialisé à encaisser.

Ce sont les acteurs cibles du système. On peut aller plus dans le détail avec des cas d’utilisation connecté à ces acteurs.



2. identifier les cas clés

Ø Le caissier gère la vente au comptoir Ø Le professionnel peut utiliser le système pour enregistrer des commandes web Ø Le magasinier utilise le système pour la préparation de la commande, la facturation

et le réassort du stock.

On a une première description de chaque cas – ici détail du cas de la vente comptoir

3. Acteurs 4. & cas accessoires



Dans un deuxième temps on se concentre sur les acteurs accessoires / secondaires. Ici le délégué commercial.

5. Détailler les séquences standard (cas vente comptoir)

On a comme acteur le caissier, et le système.

Ici on va voir le fonctionnement standard, le scénario standard du déroulement dune vente comptoir ensuite on verra qu'il y a des alternatives en grand nombre.

NB: de manière naturelle, les utilisateurs décrivent une interaction qui ne concerne pas du tout le système : l’échange de cash entre deux acteurs è cela se déroule en dehors du système. C’est naturel, quand on décrit le fonctionnement d'un système, de décrire le processus business sous-‐jacent. Cela permet de mieux comprendre le cas d’utilisation.



6. Détailler les séquences alternatives et conditionnelles (cas vente comptoir)

On peut définir à coté des séquences standard, des séquences alternatives et conditionnelles. On pourrait scanner des bons de réduction au lieu des articles par exemple. On pourrait payer autrement qu'en cash, par exemple avec des chèque repas, une carte de débit, ou de crédit, etc.

è Il faut prévoir des scénarios alternatifs à ce déroulement standard.

Autre variante possible : on arrive avec 25 fois le même article è on ne va pas le scanner 25 fois mais 1 fois et indiquer une quantité

è Séquence alternative qui consiste à encoder une quantité pour le même article.

Très vite ce formalisme devient assez compliqué, lourd quand on a des alternatives en grand nombre (ce qui est souvent le cas)



7. Structurer les cas d’utilisation

DETAIL DES ACTEURS

Une application Web est souvent dépendante des caractéristiques de ses utilisateurs

Ø l'interface homme-‐machine doit intégrer le profil des utilisateurs (culture, goûts, compétences, etc.) Exemple : les comptables préfèrent les raccourcis clavier que la souris

Ø le contenu peut varier d'un utilisateur à l'autre Exemple : pages adressées aux fournisseurs ou pages adressées aux clients

Ø les fonctionnalités peuvent varier d'un utilisateur à l'autre Exemple : utilisateur anonyme versus gestionnaire de contenu

La description des acteurs-‐utilisateurs doit être suffisamment complète

Ø pas de formalisme bien défini Ø corrélation avec une cible de marché pour les applications e-‐business



L’interface homme-‐machine est souvent dépendante de la culture de la nature des utilisateurs. Cela vaut la peine d’informer les programmeurs sur les acteurs ou utilisateurs cibles, pour présenter des lay-‐out ou contenus adaptés aux différentes cibles de la plateforme. è Pas de formalisme prédéfini ici donc on fait ce qu’on peut.

LAYOUTS DEVELOPPES EN FONCTION D’UNE CIBLE

Ici sites clairement définis pour des cibles assez diversifiées

Ø Enfants : beaucoup de graphiques et couleurs. + Contenus très allégés Ø Amateurs de hard rock : couleurs + contenu léger Ø La Meuse les sports >< La Libre : contenu nettement plus austère, plus chargé

è La Meuse : quelque chose de très épuré, avec beaucoup d’images et peu de textes et La Libre : beaucoup plus de contenus et d’informations.

FACILITES VARIABLES EN FONCTION D’UNE CIBLE



On peut même avoir des variations de contenu è Exemple d’Ethias : 3 cibles explicitées sur la page d’accueil :

-‐ particuliers -‐ entreprises -‐ collectivités

En fonction de la cible on a des variations de contenus

Ø Pour l’entreprise l’emprunt n’est pas disponible par exemple. Ø Intranet nommé MyEthias pour les particuliers et Ø Extranet sécurisé pour les entreprises ou collectivités

Les termes qui appellent les mêmes fonctionnalités sont adaptés aux utilisateurs.

CAS E-‐LEARNING : HIERARCHIE D’UTILISATEURS

• utilisateurs : haut niveau de formation, environnement universitaire, familiarisation avec les TIC

• administrateurs : informaticiens professionnels ou assimilés • gestionnaires de cours et tuteurs : public formé à l'utilisation de la plate-‐forme;

familiers à la bureautique • étudiants : public non formé à l'utilisation de la plate-‐forme; familiers à la

bureautique et très familiers à l'Internet



CAS E-‐LEARNING : DIAGRAMME DE CAS D’UTILISATION

ICHECCAMPUS par exemple.

EXERCICE : RESERVATION DE TERRAINS DE TENNIS

• Un club de tennis souhaite développer un système de réservation des terrains en ligne.

• Le système permet aux membres de visualiser les réservations déjà effectuées et de réserver un terrain après s'être identifié. Si un membre ne peut enregistrer qu'une seule réservation, les professeurs de tennis du club peuvent, eux, réserver plusieurs terrains à la fois.

• Le secrétaire administre le système en définissant les terrains disponibles et en gérant les comptes des membres qui sont en ordre de cotisation. Il peut aussi consulter les statistiques de fréquentation des terrains.

• La consultation des réservations est accessible à tout internaute afin de stimuler l'inscription de nouveaux membres. D'ailleurs, un internaute non membre peut remplir en ligne un formulaire d'inscription.



EXERCICE

Construire un diagramme de cas d'utilisation pour un distributeur automatique de billets

• retrait de liquide • gestion de la carte Proton • recharge GSM pour plusieurs opérateurs • etc.



3. DIAGRAMME D’ACTIVITE

DIAGRAMME D’ACTIVITE (UML1.*)

Modèle de la dynamique du comportement

Ø représente des actions et leur séquence d'exécution dans le temps è Les diagrammes d’activité sont très utilisés pour représenter la dynamique du système, la manière dont le système réagit, travaille, évolue au cours du temps.

Ø exemples d'applications o spécifier le comportement d'un SI o décrire un processus métier o représenter la navigation entre les pages d'un site Web

è Un site est constitué de pages qui peuvent contenir des liens vers d’autres pages du site, quels sont les chemins à inclure dans le site ? On peut illustrer cela avec des diagrammes d’activité

Complète la description des cas d'utilisation

Modélise le workflow pour une partie d'un cas d'utilisation, pour un cas d'utilisation ou pour plusieurs cas d'utilisation.

Les diagrammes d’activité sont intéressants pour décrire des utilisations complexes du système. On peut détailler des utilisations avec un seul diagramme d’activité. On peut aussi l’utiliser pour représenter l’enchainement des cas d’utilisation.

Composants essentiels

Ø des actions qui décomposent l'activité Ø des relations prédécesseur-‐successeur entre les actions Ø éventuellement l'élément qui prend en charge des actions (acteur ou système) ou le

lieu des actions



Exemple : On doit d’abord s’identifier comme membre avant d’utiliser un terrain de tennis è numéro dans les cas d’utilisation.

è Diagramme d’activité qui montre comment les différents cas d’utilisation se succèdent

Dans un diagramme d’activité, on décompose un processus, une utilisation du système en différentes actions. Puis on voit comment ces actions s’enchainent dans le temps.

ACTION & FLUX DE CONTROLE

Action = unité fondamentale de comportement

Ø manuelle ou automatisée è En fonction de ce qu’on décrit une action peut être manuelle (prise en charge intégralement par un acteur humain) ou automatisée (prise en charge par un acteur informatique et peut être prise en charge par un acteur humain (contrôle))

Ø si automatisée : modifie l'état du système, les données dans le système OU renvoie de l'information concernant l'état du système

Ø granularité typique : unité spatio-‐temporelle è Une action est censée se dérouler au même moment au même endroit

Quand on veut décrire une activité, il existe plusieurs manières de faire. Un processus peut être découpé en un grand nombre d’actions très fines ou un petit nombres d’actions plus conséquentes.

Flux de contrôle ou transition

Ø déclenche l'exécution d'une action ou d'un nœud de contrôle Ø action 2 ne peut commencer que lorsque action 1 est terminée

Dynamique du système: On a dans un diagramme, des flux de contrôle (flèches)

Attention : il s’agit de flux de contrôle dont la signification est la suivant : quand l’action 1 est terminée, alors l’action 2 peut démarrer. On ne veut représenter que ca, pas de transfert d’information de l’action 1 à l’action 2. Pas un flux de données mais de contrôle !!!



NŒUDS DE CONTROLE

è Nœud initial è départ de l'activité

è Nœud de fin d'activité

è terminaison de tous les flux de contrôle

è toutes les séquences de flux doivent converger vers le nœud de fin

è Un seul nœud initial et de fin par diagramme d'activité

Flux de contrôle :

// Une arrivée d’eau dans maison : morcelée dans différents flux, l’eau est utilisée, récoltée in fine dans des tuyaux de sortie (égouts). Une entrée et une sortie vers laquelle tous les flux doivent converger. Il n’y a pas une partie qui consomme l’eau et ne redirige pas le flux vers la sortie. è Un seul nœud de départ et un seul de fin d’activité donc. (Logiquement)

Une activité a un début et une fin ! Le diagramme d’activité ne fonctionne pas pour représenter des processus continus.

è Besoin de nœuds de contrôles complémentaires (voir suite)

NŒUD CHOICE

Ø Branchement conditionnel en fonction de conditions de garde Ø Après terminaison de l'action 1, l'action 2 est exécuté si garde 2 est vrai OU action 3

est exécutée si garde 1 est vrai Ø 1 flux entrant, n flux sortants

è Losange avec un flux entrant et 2 flux sortant.



è Quand l’action correspondant au flux entrant est terminée, on a un choix, on peut exécuter l’une ou l’autre action prédécesseur. Ce qui permet de déterminer l’action prédécesseur qu’on va exécuter ce sont des conditions de garde.

Exemple :

Ici : action demander un crédit qui s’enchaine conditionnellement :

Ø si client solvable : accorder crédit Ø si non : refuser crédit.

Ici on a que deux sorties mais on pourrait en avoir plus avec des conditions de garde d'office mutuellement exclusives.

Si on veut exécuter plusieurs actions en parallèle après la première action è alors un autre nœud est nécessaire.

NŒUD MERGE

Ø conjonction de flux Ø action 3 est exécutée après terminaison de l'action 1 OU terminaison de l'action 2 Ø n flux entrants, 1 flux sortants



Nœud avec plusieurs flux rentrant et un seul sortant. è Idée : pouvoir exécuter l’action si l’une ou l’autre action qui rentre dans le nœud est réalisée.

Exemple :

On peut expédier un article soit si la fabrication d'un article est terminée soit si on a acheté l’article a un fournisseur.

Ici on a 2 entrées mais on pourrait en avoir plus.

ATTENTION : au niveau de l’action UNE SEULE flèche peut rentrer.

NŒUD JOIN

Ø conjonction synchronisée de flux Ø action 3 est exécutée après terminaison de l'action 1 ET terminaison de l'action 2

Contrairement au choix, nœud représenté par une barre horizontale dit que l’action qui sort du nœud ne peut être exécuté que quand les 2 actions prédécesseurs dont réalisées (l'un ET l’autre, et pas l'un OU l’autre !!!)



Exemple :

Ici on peut clôturer la commande si on a expédié les articles ET envoyé la facture.

On peut avoir autant de nœud qu’on veut entrant dans ce nœud de jointure.

NŒUD FORK

Ø création de flux concurrents Ø action 2 ET action 3 sont exécutées après terminaison de l'action 1

Ici on déclenche en parallèle plusieurs actions qui succèdent à une action prédécesseur.

Exemple :



Quand on a terminé d’inscrire un étudiant on va exécuter en parallèle : choisir les cours et payer les droits d’inscription.

PARTITION

Ø défini le contexte de l'activité o qui exécute l'action? o où l'action est-‐elle réalisée?

Ø partition horizontale et / ou verticale Ø optionnelle

On peut partitionner les emplacements d’exécution en horizontal ou vertical.

DETAIL DES ACTIONS

Ø le fonctionnement des actions peut être explicité

Ø pour une action réalisée par un SI – impact de l'action sur l'état des données

Exemple : post-‐conditions, i.e. affirmations vérifiées après exécution de l'action



Ø exemple : action « confirmer une commande » – une commande est créée dans le système et est reliée à un client – les quantités disponibles en stocks sont diminuées à concurrence des

quantités commandées – la liste des commandes à préparer est mise à jour

Ø pour une action qui représente l'affichage d'une page Web

– organisation de la page, attributs graphiques, contenu, etc.

Identifier les actions n'est pas suffisant pour une description fine du système d’information, chaque action doit être détaillée. Il existe plusieurs manières de faire.

DIAGRAMME D'ACTIVITES D'UN BUSINESS PROCESS (TRAITEMENT DES COMMANDES)

Ici : activité qui décrit une procédure de prise de commande. On a Plusieurs départements. On a un nœud de début et de fin.



Envoi d’une commande è Une fois quelle a été postée par le client, 2 flux de contrôle lancés en parallèle è Le client paye la commande è Le département logistique enregistre la commande è Finalement le client reçoit la commande.

Exécuter la commande sera exécuté quand TOUT ce qui précède aura été réalisé : quand préparer la commande et payer la commande a été réalisé. Et pr ce, il faut que les actions précédentes soient réalisées. è Donc 3 étapes réalisées.

DIAGRAMME D'ACTIVITES D'UN SI (CAS COMMANDE WEB)

Ici : Système de commande par internet avec navigateur et serveur web et BDD.

Navigateur Web: le processus démarre quand un client arrive sur le site pour démarrer une nouvelle commande. Ce dernier ajoute un article dans son panier et puis après 1er article, l’utilisateur ou client a un choix : ajouter un deuxième article ou continuer sa commande (calculer total etc.). Ici « choix » permet de boucler ou répéter la même action autant qu’on veut : option = ajouter un article.

On retourne vers ajouter un article è action qu’on peut faire autant qu’on veut. Boucle !

Quand client décide que sa commande est complète, on le branche vers d’autres actions.



Ensuite étape de confirmation : si confirmé on enregistre définitivement la commande mais si client abandonne, fin sans suite.

On peut arriver au nœud de fin de 2 manières différentes. Normalement on ne peut pas avoir plusieurs flèches qui arrivent dans une même action ou nœud de fin.

DETAIL DU CAS VENTE COMPTOIR

On avait vu comment détailler les séquences d'évènement pour ce cas. Voici le diagramme d’activité.

EXTENSION DES DIAGRAMMES D’ACTIVITE UML 2.01

Les diagrammes d'activité ont été largement étoffés par UML 2.0 – 2003, notamment :

Ø flux d'objets Ø gestion des exceptions Ø répétitions et exécutions parallèles de groupes d'actions Ø événements

1 Pas utilisé dans les exercices

2 Si on tape balsamiq on peut retrouver cette vidéo (Google) et utiliser en test l’outil



Dans la suite : illustration partielle des ces facilités

Ici on va voir des constructions complémentaires des diagrammes d’activité, apparus avec la version 2 d’UML. Il faut savoir quelles existent et savoir les expliquer (mais pas spécialement les utiliser dans les exercices)

OBJECT FLOWS

Ø un flux de contrôle peut porter un objet passé entre des actions Ø le même objet peut transiter par plusieurs actions qui modifient son état

Flux d’objets :

Important pour gestionnaire è souvent on voit que certains dossiers sont transformés progressivement par un processus composé de différentes actions.

Souvent les objets évoluent et changent de statut è exemple : on introduit un dossier dans unif étrangère, ce dossier va passer par différentes instances, statuts è pour expliciter cette procédure on peut utiliser les flux d’objet.

Flux d'objet est représenté par un rectangle.

Objet : grappe de donnée

Ici on voit comment une commande peut évoluer au cours du temps et être transformée progressivement par différentes actions.

Ø Enregistre une nouvelle commande è produire une commande enregistrée dans le système.

Ø On précise le nom de l’objet dans le statut.



Ø Objet produit puis consommé par action suivante. Ø Relation d’entrée sortie entre différentes actions

Une fois la commande placée, on enclenche l’action de validation de la commande. Résultat : produire une commande VALIDEE.

Transit d’actions en actions : évolution, changement de statut

INTERRUPTIBLE ACTIVITY REGION (UML 2.0)

Ø un groupe d'actions (région interruptible) peut être interrompu si un événement se produit

Ø le flux de contrôle est alors redirigé en dehors de la région interruptible

On est en train d’enregistrer une commande sur un site et à un moment donné on peut abandonner la commande, pendant que le processus en cours. (N’importe quand)

Exemple : après chaque action, on fait un test : continuer ou abandonner

C’est très lourd si il y a beaucoup d’actions è Il faut tester à la fin de chaque action.

Solution : identifier une zone interruptible : ensemble d’actions qui s’enchainent mais peuvent être interrompues à n’importe quel moment. è Délimitée avec pointillés

è Permet de casser la chaine de traitement en cours pour pointer vers d’autres choses comme par exemple ici un abandon de la commande. Dans cette chaine on peut avoir une interruption à n’importe quel moment.



EXPANSION REGION (UML 2.0)

Ø un groupe d'actions (région d'expansion) peut être exécuté plusieurs fois en séquences itératives ou en parallèle

Ø consommation d'objets entrants et production d'objets sortants Exemple : itération de la fabrication d'un produit fini à partir d'une matière première

Dans certaines situations on peut être amené a répéter une série d’actions pour traiter des matières premières ou des dossiers rentrant ou autre : des objets rentrant dans un processus.

Ici : zone interruptible répétée autant de fois qu’on a d’objets rentrant dans ce process délimité par les pointillés « zone interruptible ».

On a l’action de démarrage de la production, puis les matières premières à traiter. Pour chaque objet rentrant dans processus itératif on a des produits finis.

Si jamais le produit fini est correct, qu’il fonctionne bien, on va le stocker et il va être emmagasiné dans un stock d’objets sortant de ce processus.

Ici, une interruption peut être appelée au niveau de l’itération même.

Ce n’est pas vraiment un nœud de fin de l’activité mais un nœud de fin de l’itération.

Idée : traiter de manière itérative des actions de la zone interruptible en fonction des objets rentrant.

>< Cas précédent : on faisait une fois et on pouvait interrompre a n’importe quel moment.



WAIT TIME ACTION (UML 2.0)

On peut représenter une échéance précise dans le temps dans un diagramme d’activité.

Ici : Commandes préparées è il faut qu’il soit 16h et à ce moment là, on peut expédier la commande.

« Wait Time Action » est considéré comme accompli à partir de 16h. Si les commandes sont préparées à 16h30, l’expédition démarrera à 16h30, mais à partir de 16h c'est bon. (Considéré accompli)

è 2 processus doivent être terminés avant d’enclencher l’expédition.

ERREURS FREQUENTES

Ø oubli du sens des flux Ø action sans flux sortant Ø condition de garde présentée comme une action Ø acteur représenté comme action



Ø « Vendeur magasin » représente une action ici, mais « vendeur magasin » ce n’est pas une action, c'est un acteur. Attention de pas tout mettre dans le même sac ! Pas tout mettre dans des rectangles.

Ø Créer une vente peut déboucher sur 2 choses ici è 2 conditions de garde qui ne sont pas représentées ici pas comme des conditions de garde mais comme des actions or ce sont des tests, pas des actions

Ø Pas oublier le sens des flèches !!!! Mettre des sens !!! Ø On a oublié de connecter un flux sortant vers un nœud de fin or tous flux sortant

doivent converger vers un nœud de fin.

DIAGRAMMES D’ACTIVITE ET SITES WEB

Dernière application : représentation de la navigation au sein d'un site web

Ø reprend les séquences de navigation entre les pages – action è afficher une page – transition è hyperlien

Ø nécessite d'identifier les pages – informationnelles – applicatives Ø la logique de certaines pages (surtout les pages applicatives) doit être explicitée

– formalisme : diagrammes d'activité Exemple : home banking

Ici le flux de contrôle représentent des hyperliens et les actions correspondent à l’affichage d’une page du site.



Attention : dans un système e-‐business il existe 2 catégories de pages : les pages statiques et les pages applicatives. Ce dernier type de page modifie les données du système (exemple : permet d’enregistrer un nouveau virement, transforme les données è mécanisme peut être décrite avec diagramme d’activité traditionnel).

è Utilisation traditionnelle pour décomposer un processus ou application plus spécifique

EXEMPLE DE NAVIGATION

Ici un nœud de départ pointe vers une page d’accueil. A partir de la page d’accueil, on peut naviguer vers différentes pages. Chaque fois, il y a des conditions de garde qui déterminent le chemin a suivre au niveau des connections (niveau des hyperliens).

Une action symbolise l’affichage dune page.

Souvent on part de la page d’accueil, on visite d’autre page et à la fin de chacune de ces pages on converge vers un retour vers la page d’accueil. Plein d’autres modèles sont possibles.



DETAIL DE PAGE APPLICATIVE

On peut représenter le fonctionnement dune page applicative è exemple de la page de contact : enregistre une demande de contact

EXERCICES

LIVRAISON DE COMMANDE

Ø Une entreprise de vente de PC par Internet organise son activité comme suit. Ø Un client enregistre une commande sur le site de l'entreprise. Le département

ventes vérifie alors la commande. Si le solde des paiements en cours du client est supérieur 1000, alors la commande est annulée. Sinon le traitement de la commande se poursuit en vérifiant les stocks disponibles pour les articles de la commande.

Ø Si les stocks sont suffisants, le département ventes édite une facture et le service expédition prépare la commande. Ensuite, ce même service expédie la commande en joignant la facture au colis.

Ø Si les stocks sont insuffisants, le département ventes met la commande en attente et enregistre une nouvelle commande fournisseur pour les articles concernés.



SAISIE DE COMMANDE VIA LE WEB

Ø Un système de commande sur le Web est pensé comme suit: Ø le système affiche une page d'accueil à partir de laquelle l'internaute peut choisir

une rubrique de produits en s'identifiant éventuellement au préalable; Ø au sein d'une rubrique, l'internaute sélectionne un ou plusieurs articles à

commander; Ø l'internaute peut naviguer vers une autre rubrique pour sélectionner d'autres

articles; Ø si l'internaute a sélectionné tous les articles qui l'intéressent et ne souhaite plus

consulter d'autres rubriques, le système lui montre alors le récapitulatif de sa commande et l'invite à s'identifier si ce n'est déjà fait;

Ø l'internaute clôture la transaction en confirmant la commande.

WEB BANKING

Ø DuoDos est une nouvelle banque durable qui souhaite développer un système de Web-‐banking. Monsieur Janssens, qui n’est pas informaticien, a une idée plus ou moins précise du fonctionnement du système qu’il a tenté de décrire ci-‐dessous.

Ø Un client arrive sur le site et commence par s’identifier. S’il n’y parvient pas après trois tentatives successives, l’accès au Web-‐banking est bloqué et le système affiche un message demandant au client de contacter son agence.

Ø En cas d’identification fructueuse, le client peut soit consulter des comptes, soit ajouter un bénéficiaire d’un (futur) virement, soit demander d’ouvrir un nouveau compte.

Ø Lors de la consultation des comptes, le client peut soit visualiser le détail des mouvements d’un compte particulier, soit enregistrer un virement. Pendant la consultation des mouvements, le client peut visualiser des opérations plus anciennes en cliquant autant de fois qu’il le souhaite sur un bouton « opérations antérieures ».

Ø Pour enregistrer un nouveau virement, le client doit en même temps préciser le montant ainsi que la communication et choisir un bénéficiaire dans une liste. Quand ces deux opérations sont terminées, il peut alors confirmer ou abandonner le virement.

Ø Pour ouvrir un compte, le client doit remplir un formulaire en ligne.



4. DIAGRAMME DE CONTENU

Ø les contenus ont des formes très variées – données structurées régulières (données bibliographiques) – images, textes non structurés, audio, vidéo, etc. – contenus importés d'autres applications (Exemple : prévisions météo)

Ø la représentation des données structurées est spécifiée avec les modèles de données classiques (Exemple : entité/association)

– les données structurées sont le plus souvent gérées par un SGBD – autres formes de contenus : pas de représentations standard au niveau

conceptuel

Pour le contenu à poster sur le site, pas de formalisme. On les communique brutes aux informaticiens.

L’interface homme-‐machine est très importante, surtout dans commerce électronique.

Spécifier allure d’un futur peut se faire de plusieurs manières :

Ø utiliser des outils de maquettage Ici démonstration d’un système è balsamiq2 : En quelques clics on peut nous même donner une idée a l’informaticien de l’allure souhaitée de notre future site (Cf. vidéo). Ici il s’agit de créer une interface. On ne crée pas un système ici. Ici on a une idée de ce qu’on veut et on crée l’allure dune page. Ce n’est pas un site mais juste une maquette graphique. On peut l’envoyer aux programmeurs.

2 Si on tape balsamiq on peut retrouver cette vidéo (Google) et utiliser en test l’outil disponible en ligne.



EXEMPLES DE REPRESENTATIONS DE CONTENUS



5. DIAGRAMME D’INTERFACE

Ø fait intervenir des graphistes, des ergonomes, etc. qui s'assurent de la lisibilité et de l'ergonomie du site

Ø composants typiques : – schéma de structure de page – charte graphique

Ø la charte graphique détermine les attributs visuels du site – couleurs des contenus et des fonds – styles de textes (polices, fontes, etc.) – styles des boutons de navigation et des hyperliens – format des images, etc.

Ø le schéma de structure représente les pages de manière abstraite – indépendamment d'une technologie cible

EXEMPLE DE SCHEMA DE STRUCTURE DE PAGE

Ø formalisme libre et non standard Ø les outils de développement Web proposent des structures génériques



EXEMPLE DE STRUCTURE GENERIQUE DE PAGE

EXEMPLE DE CHARTE GRAPHIQUE



6. ETUDE DE CAS

On en est à l’issue de l’activité de spécification

Quand on enclenche un projet e-‐business il y a 2 étapes clés a produire.

Ø un document de cadrage du projet où on décrit des intentions, on motive le projet, etc.

Ø quand le projet est confirmé : rédaction d’un document de spécification ou on décrit l’ensemble du système

Si on souhaite externaliser le développement, faire appel à une société de service pour le prendre en charge, la document de spécification prend l'allure d’un cahier de charge.

Idée : définir un document qui va servir après de base contractuelle pour les échanges avec la société de service.

EXEMPLE DE CAHIER DE CHARGES

Ici on s’adresse à des fournisseurs qui ne connaissent pas nos attentes etc. donc en premier lieu, il convient de présenter l’entreprise (premier chapitre)

Ici c’est EDIBOOK, une petite maison d’édition.

Ø On a dans le premier chapitre (de présentation de la société), un historique, la structure et l’organigramme, les produits et une critique de l’existant)

Ø Ensuite, dans un deuxième chapitre, on a l’appel d’offre. è Contexte ? Motivation ? Ø Dans un troisième chapitre, on mettra les spécification du système, des besoins des

utilisateurs : repérer les différents modèles, langages de modélisation. Ø Dans un quatrième chapitre, on trouvera les besoins non fonctionnels. Ø Finalement, dans un dernier chapitre, il est bon de spécifier l’offre de service qu’on

attend du fournisseur.

On envoie ce cahier de charge à une dizaine de fournisseurs è l’analyse est plus simple si on impose une certaine structure dans les réponses. On peut demander au fournisseur de préciser le planning, etc.



CONTENU

APPEL D’OFFRE

Le cahier des charges doit permettre au fournisseur de réaliser une estimation des coûts de développement. Il sera intégré dans le contrat de service passé avec le fournisseur choisi.

EDIBOOK est prêt à adapter légèrement ses attentes, moyennant accord, si le fournisseur propose une solution progicielle existante, par exemple une plate-‐forme open source ou un outil développé par le fournisseur lui-‐même.

EDIBOOK n'impose aucun standard technologique pour le développement. La fonctionnalité du système, la qualité de la solution, son coût et l'expertise du fournisseur sont les principaux critères de choix.

Après une première sélection sur la base de l'analyse des offres écrites, les fournisseurs potentiels retenus seront contactés pour un approfondissement de leur offre.

La propriété de tous les éléments du système conçus sous la responsabilité du fournisseur (développements spécifiques, charte graphique, dessins d'écran, etc.) est transférée sans exception ni réserve au client.

Le fournisseur assumera seul la responsabilité de l'offre et du développement. En cas de sous-‐traitance, il restera seul maître d'œuvre.

La réception provisoire sera réalisée quand :

Ø tous les matériels et logiciels seront installés, testés et mis en œuvre conformément aux spécifications du présent cahier des charges ;

Ø la formation aura été dispensée.



La réception définitive sera réalisée au plus tôt 6 mois après la réception provisoire.

CAS D’UTILISATION



ACTIVITE



ENTITE/ASSOCIATION

INTERFACE



BESOINS NON FONCTIONNELS

On peut, par exemple, imposer des minimums de performance ou de sécurité, ou encore des compatibilité avec un existant (exemple : travailler avec environnement Apple, Mac, on peut imposer que le système puisse communiquer avec)

OFFRE DE SERVICE

On dit quelles sont nos attentes par rapport à une offre de service.



è Spécifier un niveau de service (fréquent)

Ø On impose par exemple des délais d’intervention en cas de panne. Ø On impose que les problème soient résolus dans les 8h ouvrables maximum sous

peine de pénalités de retard.

è Table des matières qui va faciliter largement la réponse



5. REALISATION

Ici on aborde l’activité de réalisation du système.

D’abord on détaillera les activités de conception et de mise en œuvre puis nous verrons les outils de mise en œuvre employés par les informaticiens pour la création des systèmes e-‐business, et pour finir nous verrons les techniques clés qui interviennent le plus fréquemment dans le développement de ces applications.

La réalisation du système couver des tâches essentiellement techniques, prises en charge par les informaticiens. La réalisation du système implique au premier chef les informaticiens. Même si les utilisateurs sont mis à contribution de temps en temps pour par exemple spécifier leur demande ou évaluer des prototypes intermédiaires. La réalisation du système implique 2 choses :

1. Conception : établir les plans détaillés du système sous un angle technique et non plus fonctionnel.

2. A partir de ca il sera possible au programmeur de créer concrètement le système en produisant le code des programmes qui feront partie de ce système. è créer concrètement le système

Ces activités techniques de conception et mise en œuvre s’appuie sur des outils de développement, qu’on appelle parfois aussi des outils de génie logiciel, et la mise en œuvre (fabrication concrète) font appel à des technologies spécifiques (ex : XML).

1. CONCEPTION ET MISE EN ŒUVRE

CONCEPTION

Jusqu’à présent on a toujours considéré le système comme une boite noire en se concentrant sur ses facilités et les fonctionnalités ; mais on ne s’est jamais concentré sur la structure et son organisation interne. Ex : quel serait le schéma de la base de donnée sous-‐jacente au système et les programmes d’application qui vont permettre de traiter ces données. C’est justement l’objectif de la conception.

Objectif de la conception :

-‐ établir, à l’intention des programmeurs, les spécifications du système à construire sous un angle technique, par exemple en fonction de choix technologiques établis è établir des plans techniques, des spécifications techniques, qui seront des lignes de conduite pour les programmeurs.

-‐ On dit souvent que la conception décrit le « comment » plutôt que le « quoi ». -‐ Dégager une réponse aux besoins par l’application des TIC



Quelques exemples de tâches qui interviennent dans l’étape de conception

-‐ choisir les TIC (technologies) les plus adaptés aux spécifications, aux attentes des utilisateurs. Ex : choisir un système de gestion de BDD ou un langage de programmation plutôt qu’un autre.

-‐ spécifier l’architecture et les composants du système -‐ concevoir un schéma de base de données -‐ imaginer et décrire les interfaces du système -‐ identifier l’ensemble des programmes à écrire

Le travail de conception va décrire le système sous un angle technique, et comme toujours, pour représenter le système, on va faire appel à des formalismes. Cependant, ici les techniques de représentation du système seront relativement techniques (parce qu’on se rapproche de la machine) et très spécifiques au technologies (TIC) qui ont été choisies pour développer le système. Cependant, les représentations restent essentiellement graphiques comme on va le voir ci-‐dessous.

Même dans ce travail fort technique, les utilisateurs doivent toujours rester actifs, par exemple pour préciser leurs besoins ou valider certaines parties du système en développement. è Contribution ponctuelle des utilisateurs (précisions, besoins non fonctionnels). Exemple : validation de la maquette graphique

Raffinement de la description du système décrit lors de l'analyse en fonction d'un contexte technologique

EXEMPLE DE REPRESENTATION

Voici quelques exemples de représentation au niveau de la phase de conception.

Exemple : Conception d'un schéma de base de données relationnelle à partir des spécifications entité/association.



MISE EN OEUVRE

La mise en œuvre a pour objectif de construire, ou programmer le système. C’est le gros d’un projet de développement informatique.

Exemples de tâches réalisées lors de cette activité de mise en œuvre :

-‐ génération et configuration de la base de données -‐ écriture du code des pages d’un site WEB ou d’un programme d’application -‐ paramétrage et intégration de composants standard

Formalisme : langages informatiques

EXEMPLE DE REPRESENTATION

Au niveau de la mise en œuvre, on produit la description la plus fine, la plus ultime du système, à savoir du code interprétable par les machines. Ici, on voit un exemple d’inscription SQL pour créer une base de donnée, c’est le niveau de détail le plus fin qu’on puisse imaginer pour une base de donnée.



2. OUTILS DE DEVELOPPEMENT

Pour avoir une idée de la manière dont les programmeurs produisent effectivement le système, on va voir quelques exemples d’outils de développement largement utilisés pour la production d’applications e-‐business. On va voir essentiellement 3 exemples :

-‐ les outils de développement classiques -‐ les générateurs automatiques de sites web -‐ les package et plus particulièrement un exemple d’outil de content management

OUTILS DE DEVELOPPEMENT CLASSIQUES

Tout programme informatique est composé d’une série d’instructions qui peuvent être exécutées par un ordinateur. Il est nécessaire de disposer d’éditeurs de code pour permettre au programmeur de créer les lignes d’instruction à exécuter par l’ordinateur.

Pour développer des systèmes e-‐business très spécifiques, on utilise des éditeurs adapter, pour développer des sites web, des chartes graphiques, ou des animations graphiques qui vont enjoliver un site de vente en ligne par exemple.

è Le système est explicitement programmé par les informaticiens à l'aide d'outils comme :

Ø des éditeurs de code pour créer des pages WEB. Exemple : Macromedia Dreamweaver, Adobe Golive, Microsoft Visual Studio

Ø des logiciels de graphisme et d'animation. Exemple : Adobe Photoshop et Illustrator, Macromedia Fireworks et Flash

Avantages Inconvénients Ø développement de systèmes bien

adaptés à la demande Ø coût du développement Ø besoin de compétences

professionnelles

Construire un système e-‐business de cette manière permet de coller à des besoins très spécifiques des utilisateurs, si ceux-‐ci ne trouvent pas leur bonheur dans une offre progicielle déjà existante.

Malheureusement, si c’est un projet très personnalisé, cela a un cout : essentiellement le cout de main d’œuvre lié à l’écriture des programmes. En plus l’écriture d’instruction d’un système e-‐business n’est pas à la portée du premier venu, il faut une formation, un bagage technique, parce qu’il faut en général combiner des technologies diverses et parfois complexes.



EXEMPLE : DREAMWEAVER

EXEMPLE : MICROSOFT VISUAL STUDIO

Le marché propose toute une série d’outils de développement pour des systèmes e-‐business et sites web en particulier, par exemple : Dreamweaver qui est une des références du secteur, ou Microsoft Visual Studio (printscreen ci-‐dessous). On peut voir du code, produit par les programmeurs et en-‐dessous, une prévisualisation du site.



GENERATEURS DE SITES

Une autre manière de générer des sites web est d’utiliser des logiciels spécialisés pour créer des sites web.

Le système est créé par un logiciel spécialisé sur base des directives de l'utilisateur

Ø pas de programmation, mais utilisation d'assistants électroniques pour créer des pages WEB

Ø Exemple : http://www.weebly.com/, MS-‐Publisher, Google Site

Avantages Inconvénients Ø accessibles à des non-‐informaticiens Ø développement rapide Ø coût faible

Ø limites fonctionnelles rapidement atteintes

Ø réaliste essentiellement pour des sites basiques ou standard

L’avantage de cette approche est qu’elle consomme très peu d’énergie, elle est relativement accessible à des non-‐informaticiens puisqu’il s’agit simplement de spécifier l’allure du site, son organisation, et à travers des assistants électronique, ce système de production automatique va créer un site avec un certain nombre de fonctionnalités standards.



C’est très intéressant pour des sites très simples mais malheureusement, dés qu’on tombe dans des demandes un peu plus spécifiques, on atteint très vite les limites fonctionnelles de ces outils.

EXEMPLES

Le système Weebly en ligne est un exemple de créateur automatique de site. Cf. la démonstration sur Icheccampus.

PACKAGE ET CONTENT MANAGEMENT

PACKAGE

Une troisième approche pour développer des systèmes e-‐business est le recours au package.

Un package est un ensemble logiciel avec toute une série de fonctionnalités cohérentes, par exemple pour gérer un magasin en ligne ou pour développer une plateforme e-‐learning. Ces solutions, relativement riches au niveau fonctionnel ont l’énorme avantage d’être paramétrables (du moins, dans une certaine mesure). è Solutions complètes et paramétrables

Ø souvent développées pour des métiers ou des fonctions spécifiques Ø Exemple : magasin en ligne, gestionnaire de contenus, ERP Ø solutions propriétaires ou libres Ø Exemple : OS Commerce, Joomla, Compiere, Open ERP



Avantages Inconvénients Ø réutilisation de solutions existantes Ø développement relativement rapide

Ø coût du développement pour les fonctions non couvertes

Ø besoin de compétences Ø dépendance dans le cas d'une

solution propriétaire

Cela permet d’éviter un redéveloppement ou un développement complet du système puisqu’on part, en quelques sortes, d’un costume prêt à porter qu’on personnalise légèrement. Les couts de développement sont fort réduits et cette solution fonctionne bien si les utilisateurs s’y retrouvent dans les fonctionnalités proposées par ces packages. Si ce n’est pas le cas, il faut réaliser des extensions parfois couteuses et complexes à ces packages, et si vraiment les besoins des utilisateurs sont trop éloignés de ce que peut offrir un package, alors on préférera un développement traditionnel.

Certains de ces packages sont en open source (en accès libre), dés lors ces packages sont soutenus par des communautés de programmeurs qui font évoluer le système. D’autres packages sont développés par des sociétés commerciales qui ne distribuent pas leurs sources, on parle alors de solutions propriétaires. L’utilisateur qui s’engage dans une solution propriétaire doit être conscient qu’il est relativement dépendant de l’éditeur de ce package propriétaire et il doit donc s’assurer que ce fournisseur, cet éditeur est fiable, notamment au niveau du service et de sa disponibilité sur le long terme.

SYSTEMES CMS -‐ EXEMPLES DE PACKAGES

Un des premiers besoins qu’on a rencontré dans l’internet, c’est de pouvoir publier de manière très facile, différents contenus à destination des internautes.

Le problème pour publier de l’information sur internet, c’est que cette information doit être formatée/présentée/organisée avec un langage qui s’appelle le HTML (on en parlera plus tard). Par conséquent, un utilisateur lambda qui veut publier le moindre document doit connaître le langage HTML pour la mise en forme de ce contenu. Avec les systèmes de content management, on peut séparer contenu et mise en forme. Plus précisément, grâce à ces outils CMS (Content Management System), l’utilisateur peut simplement déclarer un contenu à publier, la mise en forme sur le site web sera prise en charge automatiquement par le CMS. Par conséquent, les CMS sont des exemples de package très populaires aujourd’hui.

Exemples de CMS disponibles en open source sur le marché : Joomla, Xoops, Typo3, Open CMS, SPIP (regarder la démonstration de Joomla pour découvrir les fonctionnalités offertes par ce système CMS)



è Content Management System (CMS) = système de gestion de contenu

Ø outils de développement et mise à jour de sites Ø principe : séparer le contenu de sa présentation

o un utilisateur peut agir sur le contenu d'une page sans se soucier de sa mise en forme

o indépendance de l'utilisateur vis-‐à-‐vis de l'informaticien pour mettre le site à jour (la mise en forme d'un page nécessite des compétences techniques, comme la connaissance du HTML)

Les systèmes CMS offrent de très nombreuses facilités, en voici quelques exemples :

Ø import de données de sources variées è la gestion de données en format très variés (du textes, des images animées, des worksheets, …)

Ø ces contenus peuvent être rangés dans des catégories et puis des sous-‐catégories è catégorisation de contenus (par Exemple à travers des FAQ ou forums)

Ø d’autres facilités sont liées au contrôle des différents contenus. è workflow management pour l'édition et la mise en ligne de contenus

Ø exemple ci-‐dessous: un auteur déclaré dans la plateforme CMS pourrait poster un nouvel article et avant publication, on pourrait imaginer que cet article soit validé par un administrateur ou un gestionnaire du site. Le diagramme d’activité nous montre un exemple de procédure réalisable et contrôlable avec ces systèmes de content management.



EXEMPLE: JOOMLA (VOIR SLIDES)

Le contenu est inséré sans tenir compte de sa disposition sur le site

Ø mise en forme du site automatique et indépendante du contenu è Indépendance entre mise en forme et contenu

Joomla fournit des facilités pour :

Ø classifier les articles en sections puis en catégories Ø imprimer un contenu, télécharger un contenu en PDF ou envoyer le contenu par

email Ø rechercher des contenus, notamment sur base des métadonnées Ø valider des contenus d'un utilisateur "auteur" par un utilisateur "éditeur"

EXEMPLE : OPEN ERP (VOIR SLIDES)

3. TECHNIQUES CLES

Ici on va voir les principales technologies utilisées par les informaticiens professionnels pour développer des systèmes e-‐business.

PAGES DYNAMIQUES

HTML (HYPERTEXT MARKUP LANGUAGE)

Une des technologies fondatrices de l’internet, c’est le langage HTML. Dés le début de cette technologie, la plupart des contenus qui circulaient (et circulent toujours) sur l’internet, sont formatées dans ce langage. Format è le langage a pour objectif de mettre en forme du contenu à afficher dans un navigateur.

Le fonctionnement de ce langage est le suivant : le contenu brut est encadré de balises ou signaux qui indiquent au navigateur quelle mise en forme il faut appliquer au contenu.

Exemples de balises

Ø <B>texte en gras</B> è contenu encadré par des balises « B » et « End B » pour « bold » et « end bold » ou « /bold ». Le résultat sera l’affichage en gras de ce texte dans un navigateur.

Ø Une autre balise super importante, liée à la nature hypermédia et hyperlien de l’internet est la balise HREF qui permet de définir au sein d’une page web un pointeur vers une autre page : <A HREF = 'URL du document pointé'>



Le contenu et mise en forme sont intimement mêlés dans une page HTML è lourdeur de la mise à jour : mettre à jour un élément d’information à véhiculer sur le web, ou à publier à travers un site web, nécessite la maitrise de ce langage HTML puisque le contenu et la mise en forme sont ici intimement mêlés.

Sert à coder des contenus stables à échanger via Internet

Ø page Web statiques Ø Exemple : présentation d'entreprise

EXEMPLE DE PAGE STATIQUE

Fenêtre de droite : exemple de code HTML. Le contenu apparaît en noir et les balises apparaissent en bleu avec des délimiteurs < et >.

Fenêtre de gauche : rendu de ce code HTML.

On peut facilement faire la connexion entre la nature des balises et la manière dont le texte est rendu à l’affichage.

XML (EXTENDED MARKUP LANGUAGE)

Une évolution du HTML est le XML. Il s’agit toujours d’un langage à balise dont l’objectif est de transférer via l’internet des données semi-‐structurées, mais ici les balises décrivent la structure de l’information et non plus sa mise en forme. Grâce à des standards complémentaires au XML on arrive à une meilleure séparation entre contenu et mise en forme et surtout on introduit dans les informations du web une notion de schéma de donnée, ce qui facilite par exemple la recherche d’informations sur internet ou l’interprétation automatique des contenus par des ordinateurs.

è XML = Language de balisage standard pour l'échange de données

Ø transmission d'information (semi-‐) structurée dans un mode texte Ø les balises sont libres et décrivent la structure du contenu



Avantages

Ø séparation entre contenu et mise en forme, contrairement au HTML Ø notion de schéma : les balises décrivent les structures d'information

XSL (eXtensible Stylesheet Language)

è spécifications de mise en forme des données

EXEMPLE DE DOCUMENT XML

Voici un premier exemple de document XML, ou les balises apparaissent délimitées par des < et des >. Les balises ici sont libres et l’information est organisée de manière hiérarchique. Par exemple, on a ici la description de deux restaurants, et chaque restaurant est délimité par les balises <restaurant> et </restaurant>. On constate aussi qu’on n’est pas obligé de mentionner le même nombre d’informations pour chaque restaurant. Pour « Fritkot » on n’a que le nom et le téléphone alors que pour « comme chez lui » on a aussi la rue et le chef.

Cette manière d’organiser et de véhiculer l’information est très intéressante pour les moteurs de recherche car maintenant, par exemple, FritKot est interprétable par un moteur de recherche comme étant un nom de restaurant. Donc si un internaute veut connaître la liste de tous les restaurants dont le nom est « FritKot », cette recherche sera nettement plus efficace grâce à ces méta-‐informations qui sont incluses dans les documents XML.

Cette exemple montre que le XML comprend données et structures, c’est encore le cas pour le fichier XML représenté dans la fenêtre de gauche de l’écran ci-‐dessous (ou des ouvrages



sont documentés par rapport à des auteurs, des maisons de publication, etc.) è l’organisation est de nouveau hiérarchique dans les balises XML.

Pour contrôler la mise en forme de ces informations, on peut joindre au fichier XML une feuille ou un fichier XSL, comme dans la fenêtre de droite ci-‐dessous. Combiné avec le fichier XML, le rendu est celui affiché dans la fenêtre « Bibliographie XML » è l’intérêt des feuilles XSL est qu’il est possible, en fonction de l’équipement sur lequel on souhaite consulter le document XML, de moduler l’affichage et par exemple de contrôler l’affichage pour un écran d’ordinateur portable, ou de moduler autrement l’affichage de la même information, du même fichier XML, mais cette fois-‐ci pour un smartphone, dont les possibilités d’affichage sont assez différentes de celle de l’ordinateur portable.

INTEROPERABILITE DES SYSTEMES

Aujourd’hui, les systèmes d’information des entreprises sont très massivement connectés grâce à l’internet. C’est donc l’occasion d’informatiser d’avantage encore les échanges entre ces systèmes, pour réduire les interventions humaines par exemple dans un processus de commande.

Exemple : un client voit son stock décroitre, et veut donc envoyer une commande de réassortiment auprès de son fournisseur è tout ce processus pourrait être entièrement pris en charge par des systèmes d’information, si le système d’information du client et celui du fournisseur sont capables de se comprendre, d’échanger des données compréhensibles et d’automatiser des traitements de re-‐commande.

è Comment faire interagir des systèmes hétérogènes ?



Ø Exemple : le système d'un client envoie une commande à un système d'un fournisseur

Ø Exemple : paiement en ligne délégué à un système spécialisé extérieur

Problème historique en informatique: cf. EDI (Electronic Data Interchange)

Aujourd’hui, après avoir beaucoup travaillé sur des techniques comme l’EDI (Electronic Data Interchange), notamment dans la grande distribution, plusieurs standards se dégagent pour rendre les systèmes d’information plus inter-‐opérables, notamment le XML et l’architecture orientée service.

Pistes de solutions

Ø échange de données : XML (eXtensible Markup Language) Ø échange de services : SOA (Service Oriented Architecture) Ø intégration des systèmes

Grâce au XML, on peut transférer via l’internet des données avec un descriptif de celles-‐ci, ce qui rend, par exemple, un bon de commande parfaitement interprétable par un système informatique d’un fournisseur qui recevrait un fichier XML avec les éléments de la commande.

QUELQUES APPLICATIONS DE L’INTEROPERABILITE

L’interopérabilité des systèmes a énormément d’applications, par exemple pour les entreprises commerciales qui peuvent échanger plus facilement et automatiquement des informations avec leurs tiers, leurs partenaires internes ou externes, par exemple pour externaliser la logistique.



Autre exemple : l’échange de connaissances, par exemple, au niveau fiscal.

EXEMPLE D’ECHANGES DE DONNEES

Voici un exemple concret d’échange de données qui illustre le besoin d’interopérabilité entre le back-‐office et le front-‐office.

Front office : interface de l’entreprise par rapport à ses tiers (clients ou fournisseurs)

>< Back office : prend plutôt en charge les opérations internes.

Ici, dans le schéma, on peut suivre tous les échanges de données entre le client, le site web de vente en ligne qui joue le rôle de front office ici, et le reste du système d’information qui joue le rôle de back office.

SOA (SERVICE ORIENTED ARCHITECTURE)

è Standard d'invocation de services

Ø un système client invoque un système producteur pour lui fournir un service Ø un service correspond à l'exécution d'un composant logiciel Ø Exemple : calcul d'une prime d'assurance, enregistrement d'un paiement

L’idée des architectures orientées service est de décomposer un logiciel en un ensemble de composants, chacun de ces composants rendant un certain service. Le service d’un composant peut être invoqué soit à l’intérieur, soit à l’extérieur de l’entreprise. Dans l’architecture orientée service, on a une idée de client-‐serveur à une échelle logicielle, relativement microscopique.



Exemple : en tant que courtier d’assurance, on pourrait vouloir réaliser un calcul de prime, si on ne dispose pas sur son ordinateur personnel de la routine permettant de calculer une prime, on peut alors invoquer un calcul de prime sur un serveur de la compagnie d’assurance pour laquelle on travaille, éventuellement à distance è bonne démonstration de l’interopérabilité fonctionnelle entre le PC personnel du courtier et le système d’information de la compagnie d’assurance.

è Standard d'architecture

Ø architecture = description des composants d'un système et de leurs interactions Ø SOA mène à la fois l'interopérabilité et la modularité

Plus généralement, un standard d’architecture décrit une manière dont on va décomposer un système en un ensemble de composants qui interagissent les uns avec les autres. Grâce à l’architecture orientée services, on arrive à augmenter l’interopérabilité des services (puisque cette architecture est basée sur l’invocation de services), on augmente aussi la modularité, et donc la facilité qu’il y a à modifier les différents composants, puisqu’en général, c’est plus simple de modifier un composant logiciel de taille réduite qu’un grand ensemble.

WEB Services

Ø transposition des principes SOA à l'Internet è émergence du WOA (Web Oriented Architecture)

Cette invocation de service est aujourd’hui possible à travers l’internet, les standards de l’internet le permettent, on parle donc d’architecture orientée service dans le contexte du web.

SOA : VERS UNE ARCHITECTURE MODULAIRE ET FLEXIBLE



Ici on voit deux figures qui nous aident à comprendre mieux comment une architecture orientée service s’organise.

Fenêtre de gauche : exemple de système structuré en 3 grands programmes.

è Celui du milieu : le traitement d’une commande (order processing) : dans ce traitement de commande on voit qu’il y a différentes étapes qui sont réalisées successivement, au sein d’un gros programme monolithique.

Dans une architecture orientée service, comme celle illustrée dans la fenêtre de droite, on constate que ce processus de traitement de commande est recomposé à partir de modules nettement plus réduits en taille (intitulés ici : service réutilisable.

L’avantage de cette architecture est qu’un même composant, un même service, peut être intégré dans plusieurs processus plus larges.

INTEGRATION DES SYSTEMES

Développement de systèmes intégrés è plus de besoins d'interopérabilité

Ø Exemple : ERP de gestion Ø Exemple : intégration du front office et du back office Ø solution limitée aux systèmes internes à l'organisation

Une solution radicale pour éliminer les problèmes d’interopérabilité serait de fonctionner avec un seul système. A ce moment là, il faudrait encore prévoir l’interconnexion entre le système d’une entreprise (un ERP par exemple) et les systèmes des partenaires de cette entreprise. Donc, les problèmes d’interopérabilité sont toujours présents et de toute façon, les ERP aujourd’hui sont majoritairement développés selon une architecture orientée service.



6. MISE EN PRODUCTION

Les deux dernières activités d’un cycle de développement d’un système e-‐business sont la mise en production et les tests.

Les objectifs de la mise en production consistent à basculer le SI (système e-‐business) d'un environnement de développement et/ou de test vers un environnement de production (ou d'utilisation). Après ce basculement, les utilisateurs vont exploiter régulièrement le système qui vient d’être développé.

Exemples de tâches de l’activité de mise en production :

Ø configurer le matériel et les logiciels Ø acquérir un nom de domaine Ø choisir l'hébergement Ø offrir un support privilégié aux utilisateurs è le support doit être particulièrement

important au début de la mise en production d’un nouveau système.

ACQUERIR UN NOM DE DOMAINE

Nom de domaine = identification unique de l'Internet pour une entité proposant plusieurs services

Ø Exemple d'entité : entreprise avec un réseau de serveurs Ø Exemple de services : site Web, messagerie électronique Ø l'identification correspond souvent au nom de l'organisation proposant ces services Ø Exemple : www.post.be, smtp.skynet.be, ftp.entreprise.be

Top Level Domains (TLD) – gérés au niveau international. Exemple : .com, .edu, .org

Domaines nationaux

Ø Exemple : .be, .fr Ø gestion en Belgique : dns.be Ø redevance annuelle

On va maintenant aborder quelques aspects pratiques du déploiement et de la mise en production d’un système e-‐business. La première chose à faire : être connu et identifié è pour cela il faut un nom de domaine. Ce nom de domaine correspond souvent au nom de l’organisation qui propose des services comme un site web, de la messagerie électronique ou encore de l’échange de fichiers.



Les domaines sont organisés de manière hiérarchique, par exemple : tous les domaines d’extension « .com » font référence aux entreprises à vocation commerciale ; d’autres classifications par pays, par exemple, font référence, pour « .be » par exemple à un ensemble de sites qui sont localisés en Belgique.

.BE

Concrètement, en Belgique en tous cas, pour réserver un nom de domaine, il faut aller sur le site www.dns.be, pour enregistrer le nom de domaine, pour autant qu’il soit unique et payer une redevance annuelle, relativement modeste.

HEBERGEMENT D’UN SITE

Une autre question pratique à régler est la localisation de l’hébergement du système. è où héberger son site Web? 2 possibilités :

Ø soit le système est localisé sur les propres équipements de l'organisation (housing) : au sein même de l’entreprise, sur ses propres serveurs, sur sa propre infrastructure

Ø soit le système est hébergé auprès d'un hébergeur externe dont c’est le métier (hosting)



Dans tous les cas de figure, on attend d’un système web

Ø une grande disponibilité (7/7, 24/24) Ø une grande sécurité è Exemple : protection contre les pannes matérielles,

l'incendie, le vol, l'intrusion, etc. Ø un certain support concernant les technologies utilisées par le site

Aujourd’hui, avec l’avènement du cloud computing, de plus en plus d’entreprises préfèrent héberger leur système à l’extérieur pour bénéficier d’un niveau de service, d’une disponibilité qu’elles ne peuvent parfois pas s’offrir elle-‐même de manière autonome.

EXEMPLE D’OFFRE D’HEBERGEMENT

L’offre d’hébergement croit sans cesse et les tarifs diminuent constamment, ce qui est une bonne nouvelle pour les utilisateurs. Aujourd’hui, les espaces d’hébergement deviennent très importants, relativement flexibles, notamment grâce au cloud computing.

Certains acteurs de l’industrie de l’internet mettent à disposition des data centers qui sont constitués d’un grand nombre de serveurs très puissants qui peuvent être configurés en fonction des demandes des clients.



7. TEST

La vérification de la qualité, et donc le test de qualité des produits intermédiaires est permanent et s’étale tout au long du cycle de développement. L’activité de test vise à une vérification permanente de la qualité et ce, à tous les stades du cycle de développement. L’idée est de voir si la correction des erreurs qui ont été identifiées lors des tests, fait partie intégrante de cette activité de test. Des petites erreurs qui peuvent être corrigée rapidement peuvent être intégrées et donc budgétées au niveau de l’activité de test, par contre, si des défauts majeurs sont identifiés alors, peut être qu’un nouveau sous-‐projet de correction d’erreur doit être mis en place.

Objectifs :

Ø vérifier continuellement la qualité Ø identifier les défauts de qualité et y remédier

Exemples de tâches :

Ø planifier les tests tout au long du cycle de développement et vérifier la qualité des délivrables intermédiaires

Ø établir des scénarios d’utilisation à confronter au système Ø documenter les erreurs et planifier les corrections

èL’activité de test est vue par la plupart des gens comme contraignante et peu productive, ce qui pousse à systématiser cette activité de test dans le cycle de développement, avec une planification soignée, ou on a bien identifié des jours et des acteurs pour réaliser ces phases de test. On peut aussi s’appuyer sur des scénarios d’utilisation les plus complexes possibles pour vérifier la qualité du système, et finalement, on suggère aussi de bien documenter les erreurs rapportées pour les mettre dans un pipeline de tâches de correction.

La phase de test est présentée après la mise en production, mais elle s'étend pendant tout le développement

QUALITE D’UN SYSTEME E-‐BUSINESS A TESTER

La qualité d’un système e-‐business recouvre de très nombreuses dimensions. Il y en a en tous cas au moins 3 qu’on peut clairement identifier :

-‐ les facteurs de qualité techniques -‐ les facteurs de qualité fonctionnels -‐ les facteurs de qualité ergonomiques

Exemple de facteurs de qualité qu’il faut évaluer à l’issue d’un développement



Technique

Ø conformité : respect des standards Ø performance : temps de réponse acceptables à pleine charge Ø sécurité : résistance face aux (potentiellement nombreuses) attaques Ø compatibilité : fonctionnement correct dans différents environnements Ø interopérabilité : interaction correcte avec d'autres systèmes

Au niveau technique, il faut par exemple vérifier que le système respecte les standards de l’internet è par exemple : que les sites web respectent à la lettre près les spécifications du HTML. On attend aussi d’un système web, une performance raisonnable, et cela pose parfois problème dans des environnements massivement multi-‐utilisateurs, avec un nombre d’utilisateurs difficile à anticiper (il peut s’agir d’une population d’internautes très vaste à certains moments, par exemple lorsqu’une entreprise réalise une action promotionnelle forte, on peut avoir des pics qui sont difficiles à supporter par l’infrastructure en place.)

Fonctionnalité (facteur de qualité lié à la fonctionnalité

Ø réponse aux besoins en termes de contenus et de traitements Ø validité des contenus (exactitude, complétude, etc.) Ø flexibilité : contenus et traitements modifiables et extensibles

Un exemple de facteur de qualité lié à la fonctionnalité c’est la réponse aux besoins des utilisateurs en terme de fonctionnalité mais aussi (et ce n’est pas toujours évident à valider) la qualité des contenus postés sur un site web, notamment si plusieurs acteurs peuvent alimenter le site web. Exemple : Wikipédia avec son système de validation et son grand nombre d’auteurs potentiels è la validation de ces informations nécessite des procédures assez strictes.

Ergonomie

Ø facilité d'utilisation Ø clarté de la navigation

Un bon site web commercial doit être attractif : le concurrent n’est jamais très loin dans la sphère de l’internet.

TESTS AUTOMATIQUES

Nous allons maintenant voir quelques exemples de test, en commençant par des techniques de tests automatiques. On trouve sur le marché, et entre autre sur internet, de manière parfois gratuite, des outils qui peuvent valider certains aspects d’une application e-‐business, au niveau par exemple de sa compatibilité avec différents navigateurs, différents environnements d’exécution. On peut aussi tester de manière plus ou moins automatique la résistance d’un site web à des attaques classiques réalisées par des hackers.



è Applications spécialisées pour tester : la compatibilité, la performance et certains aspects de la sécurité. Par exemple : logiciels d'attaques utilisés par les hackers

Exemple : rendu de la page d'accueil dans différents environnements è http://browsershots.org

Ci-‐dessous on peut voir un exemple d’outil qui affiche le rendu d’un site dans toute une série de plateformes sélectionnées par l’utilisateur.

DELEGATION DE TESTS MANUELS

Cependant, de nombreux aspects des tests d’un système e-‐business ne peuvent pas être automatisés et, concrètement, rien ne remplace l’avis d’un acteur humain qui teste un système et qui essaye de s’y retrouver et d’évaluer la facilité d’utilisation, la disponibilité de l’information, la clarté des écrans, l’ergonomie, etc. Il existe d’ailleurs des sociétés spécialisées dans l’audit de tests qu’ils réalisent avec des pannels d’utilisateurs représentatifs de la cible è des tests de l’usabilité des applications.

è La plupart des aspects d'un système Web doivent être testés manuellement è sociétés spécialisées dans l'audit de sites (Exemple : www.usabilis.com )



RETOUR E-‐BUSINESS

En marge de la qualité intrinsèque du système, et c’est une catégorie de test un peu particulière, il est bon après quelques mois ou semaines de mise en production d’un système e-‐business d’essayer d’évaluer les retours de ce système sur le business. Il existe de très nombreux outils et indicateurs pour évaluer le succès d’un système. Par exemple, la mesure la plus évidente est la fréquentation ou encore la popularité, à savoir le nombre de sites faisant référence à notre système, ou encore, la part de chiffre d’affaires réalisé par un système de vente en ligne par rapport au chiffre d’affaires global de l’entreprise.

è Evaluation de l'apport d'un système e-‐business pour l'organisation

Ø au-‐delà des tests de la qualité intrinsèque du système

Exemples d'indicateurs :

Ø fréquentation Ø popularité : nombre de liens faisant référence à un site Ø nombre de transactions commerciales/périodes



Ø % de clients Web par rapport au nombre total de clients Ø etc.

EXEMPLE D’INDICATEURS DE FREQUENTATION

Un outil très populaire pour surveiller la fréquentation d’un site s’appelle Google Analytics. C’est un outil gratuit qui nous donne des statistiques de fréquentation selon toute une série de critères : le critère temporel, mais aussi des critères géographiques ou des critères techniques (par exemple : quelle proportion d’accès au site ont été réalisées avec un navigateur comme Firefox).



8. EXEMPLE : RATIONAL UNIFIED PROCESS

Cycle de développement proposé par la société Rational (maintenant IBM)

Cadre méthodologique plutôt qu’un processus rigide

Ø flexibilité en fonction du problème à résoudre

Organisation

Ø dans le temps : phases et itérations Ø du contenu : disciplines

ORGANISATION DU RUP DANS LE TEMPS

QUATRE PHASES

Inception Elaboration Construction Transition



1. Inception : définir la portée du projet, réfléchir sur l’opportunité. è Première description du système, on délimite le système et on définit ses utilisations pour essayer de faire une première estimation des coûts, des délais et des risques.

2. Elaboration : planifier le projet et décrire le système è comprendre la demande des utilisateurs. On modélise le système avec le diagramme d’activité, l’entité association, etc.

è Définir le système à construire è Préciser les coûts et les délais

3. Construction : réaliser le système è quand on a compris la demande des utilisateurs, on peut commencer à y répondre ; par exemple en choisissant les technologies et en produisant les prototypes successifs.

è Produire les premières versions è Tester les prototypes jusqu’à maturité

4. Transition : livraison du système aux utilisateurs (une fois que l’on dispose de la solution)

è Assurer l’autonomie des utilisateurs

DISCIPLINES

Business Modeling

Ø comprendre la structure et la dynamique de l'organisation Ø définir les besoins du système de support à l'organisation

Requirements

Ø définir et maintenir un consensus sur les besoins avec tous les interlocuteurs Ø faire comprendre les besoins aux développeurs Ø délimiter le système Ø établir un premier découpage en itérations Ø estimer les coûts et délais

Analysis & Design

Ø concevoir le système à partir des besoins Ø établir l'architecture Ø intégrer l'environnement de développement



Implementation

Ø organiser l'implémentation Ø implémenter et tester Ø intégrer les modules développés par des équipes différentes

Test

Ø identifier et documenter les erreurs Ø valider le logiciel

Deployment

Ø s'assurer que le logiciel est disponible pour les utilisateurs

Configuration & Change Management

Ø identifier et mesurer l'impact des changements à apporter

Project Management

Ø planifier, allouer les ressources et suivre le projet Ø gérer les risques

Environment

Ø mettre à disposition des développeurs un cadre de travail (outils, ligne de conduite, processus, etc.)

Ø configurer un processus de développement adapté au problème

RUB « BEST PRACTICES »

Développement itératif

Ø chaque itération produit du logiciel exécutable Ø les premières itérations prennent en charge les développements les plus risqués Ø les besoins sont actualisés à chaque itération



Gestion des besoins

Ø répertoire organisé des besoins et accord de toutes les parties Ø priorités sur les besoins instables et primordiaux Ø gestion des changements des besoins

Architecture de composants

Ø architecture : ensemble d'éléments inter-‐reliés Ø construction du logiciel par composants Ø réutilisation de composants

Modélisation visuelle

Ø les spécifications sont exprimées à travers différents modèles (graphiques) complémentaires

Ø formalisme graphique expressif et rigoureux

Vérification continue de la qualité

Gestion du changement du logiciel

Ø historique des versions Ø impact et documentation des modifications



9. MAINTENANCE ET PROMOTION

MAINTENANCE

è Pour un système en production (après le cycle de développement)

Remarque : nous sommes maintenant au delà du cycle de développement du système e-‐business. On suppose que le système est rentré en production è comment faire pour le maintenir à jour et le promouvoir dans le monde très concurrentiel qu’est celui de l’e-‐business ?

Objectifs :

Ø faire évoluer le système pour augmenter sa qualité et l’adapter à l’évolution des besoins

Ø dynamiser le contenu

Améliorer la qualité du système : c’est important car développer du logiciel exempt d’erreur est quasiment chose impossible, on peut détecter des erreurs parfois après des mois ou des années de mise en production. Et surtout, dans un environnement d’affaires très changeant, les attentes des utilisateurs, les modes, les besoins des consommateurs évoluent très vite, et donc les systèmes e-‐business qui automatisent les activités humaines doivent suivre inévitablement cette évolution.

Plus particulièrement pour les systèmes commerciaux, il faut veiller à dynamiser le contenu pour que le système reste attractif par la nouveauté et attire des clients ou des internautes non-‐clients à revenir.

Exemples de tâches :

Ø maintenance technique du système : Un travail technique d’amélioration du code. On peut d’ailleurs distinguer la maintenance corrective de la maintenance évolutive. La maintenance corrective consiste simplement à corriger les erreurs qu’on aurait détectées, tandis que la maintenance évolutive vise à adapter le système à de nouvelles demandes, à de nouveaux besoins.

Ø Finalement, la tâche de mise à jour du contenu vise à moderniser, faire évoluer en permanence l’offre d’information d’un système e-‐business. è Exemple : news sur la page d'accueil, présenter les nouveaux articles



PROMOTION

LA PROMOTION D’UN SITE WEB COMMERCIAL

Ici nous allons parler de la promotion d’un site web à vocation commerciale, comme un site de vente en ligne par exemple. Lorsqu’on veut faire la promotion d’un tel système, on vise d’abord à maximiser la fréquentation du site (objectif). Cela passe par 2 choses :

Ø assurer la réputation et la visibilité du site. Ø fidéliser les visiteurs pour essayer de transformer en les clients potentiels en clients

réels, en acheteurs réguliers.

Réputation sur internet:

Ø construction de la puissance de la marque Ø crédibilité sur Internet Ø non traité dans la suite

La réputation sur internet est quelque chose qui se construit avec toute une série de techniques (que nous n’allons pas détailler), mais la puissance de la marque, la réputation de l’entreprise contribue à la réputation sur internet notamment.

Visibilité d’un site :

Ø Comment placer le site à la portée des internautes, pour qu’il soit accessible ? Ø Comment faciliter la découverte du site et son accès ?

Exemples de tâches pour augmenter la visibilité

Ø la présence dans le monde physique (cartes de visite, publicité dans les médias classiques)

Ø le référencement dans des annuaires, moteurs de recherche et comparateurs Ø l'E-‐Mailing Ø la publicité en ligne Ø la mise en place de partenariats Ø les relations publiques en ligne

Comment faire pour promouvoir un nouveau site web de vente en ligne par exemple ? Il y a toute une série de choses à faire dans le monde physique (en dehors de l’internet). Par exemple : démontrer son existence dans les médias traditionnels, que ce soit dans la presse écrite ou dans les publicités qui passent sur la radio ou à la télévision, comme cela se fait très fréquemment (on entend souvent des URL qui sont mentionnés), ainsi que toute une série d’autres actions possibles dans la sphère des médias électroniques (c’est ce qui va être détaillé dans la suite).



REFERENCEMENT DANS LES MOTEURS DE RECHERCHE

Le point d’accès privilégié pour accéder à un site, c’est le moteur de recherche. Il est donc essentiel qu’un nouveau site soit connu et indexé par ces moteurs. Au minimum, au niveau technique, on peut spécifier dans un site, des métadonnées ou des informations spécifiquement destinées aux moteurs de recherche. Cela leur permettra d’établir des connexions entre des mots recherchés par un internaute et le site qu’on souhaite faire connaître.

Certains sites de moteur de recherche offrent des services complémentaires moyennant rémunération. Par exemple, on peut agir sur l’ordre de priorité de l’affichage du site ou encore, rémunérer pour un affichage publicitaire au sein d’un moteur de recherche.

EXEMPLE DE REFERENCEMENT – MOTEURS



Dans l’exemple du moteur de Google, il est possible, gratuitement, de spécifier à Google un nouvel URL d’un site qui vient d’être mis en ligne pour que Google l’indexe et le répertorie dans les résultats de recherche.

EXEMPLE D’ACHAT DE MOTS-‐CLES DANS UN MOTEUR

Avec Google AdWords, on peut rémunérer Google pour être prioritaire dans l’affichage d’un résultat de recherche correspondant à un terme qu’on juge pertinent par rapport à notre activité ou à notre site.



E-‐MAILING DIRECT

Une autre technique très classique pour atteindre les internautes et donc faire connaître son site ou son activité est l’e-‐mailing. Il y a deux conditions pour que cela fonctionne :

-‐ les destinataires de l’e-‐mailing doivent avoir à un moment donné marqué leur accord pour recevoir des promotions

-‐ il faut que les destinataires de l’e-‐mailing soient dans la cible de notre activité

Il existe des sites spécialisés dans l’achat ou la location d’adresses e-‐mail qui peuvent nous aider à cibler un e-‐mail correctement.

è Envoi à des adresses e-‐mail pour lesquelles les propriétaires ont marqué leur accord concernant une utilisation promotionnelle (opt-‐in)

Ciblage des internautes

Ø Achat/location d’adresses sélectionnées à des sociétés spécialisées Ø fichiers internes

Avantages

Ø ciblage Ø retour rapide Ø traçabilité (réception ≈ 90%, ouverture ≈ 30%, clic ≈ 8%, etc.)

Un e-‐mailing c’est relativement facile à faire techniquement, le retour est rapide et on peut assez facilement tracer la réaction des destinataires suite à l’envoie d’un mailing de promotion. Il existe des logiciels spécialisés de Customer Relationship Management pour tracer les réactions de ces internautes suite à l’envoi de différents e-‐mails è exemple : SugarCRM



Voici un exemple de société spécialisée dans l’e-‐mailing.

PUBLICITE – BANNERING

Une autre manière de se faire connaître dans le monde de l’internet est de louer un espace publicitaire sur un site susceptible d’intéresser des futurs clients ou les internautes concernés par notre activité. è Location d'un espace publicitaire sur un site pour y afficher un banner.

On va nous demander de rémunérer le site d’appel qui va mentionner une bannière publicitaire faisant référence à notre site. è Plusieurs techniques sont possibles pour calculer la rémunération de cet espace publicitaire :

Ø exposition (on peut faire un calcul à partir du nombre d’affichages de la bannière) Ø interaction (calcul à partir du nombre de clics sur la bannière, moins de 1% de

l’exposition) Ø performance (essayer de calculer le nombre de ventes déclenchées par des

internautes provenant du site d’appel)

Il faut veiller à ce que ces sites d’appel contenant les bannières soient consistants et cohérents avec notre cible. Par exemple, on voit mal une école de commerce afficher des



bannières publicitaires pour des entreprises funéraires. è Indispensable affinité entre le support et la cible de l’annonceur è Exemple : proposer une assurance funéraire à des étudiants

Aujourd’hui, tout internaute sait que les techniques d’annonce publicitaire sont très sophistiquées sur internet è notamment à partir de techniques de datamining, certains sites offrent des affichages publicitaires personnalisés qui intègrent par exemple la navigation antérieure de l’internaute. Si on va par exemple rechercher des articles de telle nature dans un catalogue, plus tard, en un site de météo par exemple, des bannières publicitaires concernant des articles similaires nous seront présentées. è Techniques de bannering dynamique è banners sélectionnées en fonction du profil et ou de l’historique de navigation

Aujourd’hui, des régies publicitaires qui gèrent des espaces de promotion se sont développées uniquement pour l’internet. Exemple : http://www.beweb.be è propose des espaces publicitaires dans toute une série de médias.

MISE EN PLACE DE PARTENARIATS

Comme dans le monde réel, certaines entreprises vont développer des partenariats mais dans le monde virtuel ici et ces partenariats lient souvent des entreprises avec des affinités stratégiques ou des affinités en terme de produit. è Partenariats entre alliés stratégiques , complémentaires et de taille comparable.

Nature du partenariat :

Ø échange d’espaces de promotion Ø échange de bases de données de clients Ø échange de ressources logistiques



La nature de ce partenariat peut porter sur des publicités ou des promotions croisées, mais aussi à des échanges de base de données de contacts pour des mailings croisés, voire, des mises en commun de ressources logistiques.

Ci-‐dessous, un exemple de partenariat croisé entre Intel et Toshiba : on voit clairement que les sites des 2 partenaires renvoient respectivement à la marque associée.

RELATIONS PUBLIQUES EN LIGNE

Il est important de mentionner l’importance croissante que prennent les relations publiques en ligne parce qu’aujourd’hui, l’internet a pris un espace très important (et de plus en plus important) dans la communication entre les entreprises et les consommateurs, et donc, certaines entreprises/marques sont très vigilantes concernant leur image qui est véhiculée dans différents médias de l’internet. Certaines ressources sont donc consacrées à surveiller les messages négatifs qui circulent sur les réseaux sociaux par exemple, ou encore, être justement présent sur des réseaux comme Facebook ou Twitter.

Ø ensemble des moyens déployés pour faire parler de l’entreprise dans les (e-‐)médias Ø recherche de relais écoutés par l’opinion Ø présence sur les réseau sociaux, les blogs personnels, etc. Ø contrôler les messages négatifs Ø corrélation avec le réputation



10. SECURITE

ETAT ET ENJEUX

L’ETAT DES SYSTEMES

Au départ, l’internet a été conçu pour échanger des données scientifiques et les concepteurs de l’époque n’ont pas vraiment songé ni à l’énorme quantité d’information qu’on aurait pu véhiculer via ce média, ni à toutes les applications grand public qu’on aurait pu faire de cet internet. Donc, ils n’ont pas à l’époque, intégré dés le départ une dimension sécuritaire dans cette technologie. En outre, aujourd’hui, malgré les enjeux et l’utilisation massive d’internet, on se retrouve sans système de régulation du moins à l’échelle mondiale. è Avec internet on fait de tout, sans beaucoup de contrôle et avec des technologies qui ne sont pas ultra-‐sécurisées.

è Internet =

Ø espace publique planétaire Ø sans régulation à l’échelle mondiale Ø non conçu à la base pour être sécurisé

Connexion de systèmes d’entreprise

Ø autrefois isolés de l’extérieur Ø contenant le patrimoine de données de l’entreprise

Mise en ligne de services sensibles

Ø amenant les internautes à alimenter l’Internet avec des données personnelles Ø Exemple : paiement en ligne

Ces problèmes deviennent d’autant plus aigus que aujourd’hui, la plupart des systèmes d’information des entreprises qui étaient auparavant totalement isolés sur monde extérieur sont aujourd’hui en lien/connexion direct avec le reste du monde, avec l’internet, puisque aujourd’hui, les systèmes Front Office par exemple permettent à des internautes d’enregistrer des données directement dans les systèmes d’information des entreprises de vente en ligne, par exemple. Techniquement, on a donc créé des canaux/chemins de communication qui peuvent être potentiellement piratés pour accéder à des données internes de l’entreprise qui devraient rester confidentielles. Une dernière difficulté qui se combine aux précédentes est que certaines applications de l’internet sont utilisées pour encoder, modifier, visualiser des données personnelles et sensibles. Exemple : les



applications de webbanking qui permettent aux utilisateurs d’enregistrer des paiements mais permettent aussi à d’éventuels pirates de collecter de manière détournée et sophistiquée, certaines informations confidentielles.

DEPENDANCE ACCRUE DES INTERNAUTES

Nombreux internautes utilisent massivement les applications de l’internet pour alimenter certains systèmes en données qui peuvent être personnelles, ou en tous cas devraient rester confidentielles, mais certains systèmes sont capables de produire automatiquement des données qu’on pourrait considérer comme personnelles et qui doivent être protégées.

Exemple : Smartphones équipés de système GPS et de connexion à l’internet, on pourrait concevoir que certaines applications tracent littéralement les déplacements d’un internaute et exploite ces informations à des fins publicitaires par exemple.



EXEMPLES DE MENACES

Les exemples de piratage ne manquent pas. On retiendra que certains acteurs de l’industrie informatique même, peuvent parfaitement être victimes d’attaques de la part de pirates sans scrupules.

Exemple ci-‐dessus : site de Microsoft qui a été détourné par des pirates

Exemple ci-‐dessus : site de la police fédérale qui a été hacké par un internaute de 17 ans. Cela montre qu’avec un peu de temps, un minimum de compétences et l’ensemble des outils et trucs mis à disposition des pirates par l’internet lui même, cela devient relativement facile de pirater des applications, des systèmes qui n’ont pas été correctement protégés.



Dans les exemples précédents on voyait que certains sites pouvaient avoir été piratés en modifiant leur page d’accueil, en éliminant le contenu officiel du site et en le remplaçant par un contenu pirate. Une autre forme de fraude par internet consiste à recueillir de manière totalement illégale des informations confidentielles comme des numéros de carte de crédit. C’est inquiétant surtout étant donné qu’actuellement on peut acheter des articles sur internet en fournissant quelques coordonnées è un numéro de carte de crédit et un numéro de vérification par exemple, mais on peut ne pas disposer physiquement de la carte.

Une autre forme d’attaque consiste à mettre un site hors service en le surchargeant. L’idée est de contrôler à distance et à leur insu, des machines appartenant à des utilisateurs sur lesquelles un pirate a installé un programme qu’il peut contrôler à distance et au moment venu, le pirate peut lancer l’instruction auprès d’un grand nombre de machines affectées pour que celles ci accèdent toutes en même temps à un même site. Les serveurs hébergeant ce site adressé massivement deviennent alors l’objet d’un très grand nombre de requêtes



auxquelles, techniquement, il ne peut répondre. Par conséquent, le site sera indisponible pendant une certaine période.

Mais aussi…

Voici quelques exemples de clauses d’utilisation de Facebook à lire.

Et encore…

On voit donc le grand nombre d’informations stockées par les sites internet à propos des activités des utilisateurs. Sur ICHECCAMPUS par exemple, il est possible de tracer de manière très précise l’activité des étudiants sur la plateforme.



AMPLEUR DU PHENOMENE

La plupart des attaques ne sont pas rapportée => seulement 20% des attaques déclarées (une faible proportion)

Pourquoi?

Ø mise en avant de faiblesses, image de marque Ø attaque non détectée Ø manque de maturité en termes de conscience et de solutions

Une entreprise qui voit son système d’information attaqué avec succès ne souhaite pas spécialement en faire la publicité car cela pourrait nuire à sa réputation. Exemple : une banque dont les comptes auraient été piratés perdrait la confiance de ses clients.

ENJEUX DE LA SECURITE

Ci-‐après, quelques chiffres concernant les impacts potentiels d’attaques informatiques graves. Dans certains cas c’est l’activité entière de l’entreprise qui peut être mise en péril suite à une attaque informatique.

Ø 43% des organisations doivent fermer suite à une perte de données majeure Ø indisponibilité de plus de 10 jours => fin de l’entreprise Ø dans 45% des cas : perte des données due à une erreur humaine

« Symantec a consulté 3 300 entreprises de trente-‐six pays. Intrusion dans les méandres informatiques de l'entreprise, vols de données confidentielles, usurpation d'identités d'employés, piratage et paralysie des systèmes informatiques, les opérations des pirates provoquent des dommages qui peuvent coûter cher. Ainsi, au niveau international, 20 % des entreprises évaluent les pertes annuelles causées par ces attaques à au moins 140 000 euros, imputables notamment à un ralentissement de la productivité et à la perte de données sensibles. »

DIMENSIONS CLES DE LA SECURITE

Voici les principales dimensions de la sécurité des systèmes d’information qui sont mises en péril par les pirates.

1. La confidentialité è accès autorisé à l’information

Un pirate pourrait accéder de manière illégale à des informations qu’il n’est pas censé visualiser.



2. L’intégrité è caractère exact de l’information

L’intégrité touche au caractère exact de l’information. Un pirate pourrait casser cette intégrité en introduisant dans un système des données erronées par exemple.

3. La disponibilité è information accessible et utilisable

La disponibilité de l’information qui peut aussi être mise en péril par exemple par des attaques massives de PC infectés qui mettent un site hors service pour une période déterminée

4. L’authenticité è la garantie de l’identité d’une entité

Comment garantir qu’une information disponible dans un système d’information est bien authentique, n’a pas été falsifiée par un pirate.

SOLUTIONS

Ici nous allons voir quelques solutions possibles pour gérer la sécurité des systèmes d’information.

Un préalable à la mise en place de mesures sécuritaires pour un système d’information est de se convaincre des problèmes et menaces potentielles et surtout des enjeux et des impacts que des risques de sécurité peuvent avoir sur le système d’information et sur l’activité de l’entreprise. è prendre conscience des problèmes et des enjeux.

Après cette prise de conscience, on peut penser à déployer une gestion proactive de la sécurité. Cela implique au minimum 3 choses.

-‐ il faut tout d’abord songer à une gestion intégrée de la sécurité parce que la sécurité d’un système d’information correspond au niveau de sécurité du maillon le plus faible. Tous les éléments du système et de l’infrastructure doivent être protégés contre des attaques potentielles, que ce soit les bâtiments, le logiciel ou le matériel. è accès aux bâtiments, gestion des mots de passe, sécurisation des infrastructures, sécurisation du logiciel, etc.

-‐ deuxièmement, la gestion de la sécurité doit être intense, en profondeur, et donc ce que les spécialistes suggèrent, c’est de multiplier les obstacles pour qu’en cas de rupture d’une digue de sécurité, un autre rempart se dresse devant les hackers.

-‐ Troisièmement, la gestion de la sécurité doit être permanente et dynamique parce que les types et techniques d’attaque évoluent sans cesse, il faut donc rester vigilant face à l’imagination débordante des pirates.



Pour sécuriser un système d’information on va d’abord essayer de renforcer son niveau de sécurité (prévenir) en évitant les points faibles, les vulnérabilités du système.

Une fois qu’un système est mis en exploitation, on va mettre en place une surveillance, un monitoring pour détecter les menaces et les incidents de manière à pouvoir les contrer.

Si une menace a un impact négatif sur le système, il faut gérer ces attaques et leurs effets en corrigeant les effets de cette attaque selon, si possible, un plan d’action déjà rédigé, déjà pensé au préalable.

APPROCHE MULTIDIMENSIONNELLE DE LA SECURITE

La sécurité ou la sécurisation d’un système d’information a plusieurs dimensions :

-‐ Dimension technique : il s’agit au niveau technique de protéger des systèmes par des mesures techniques de sécurité.

-‐ Dimension économique : ces technologies/techniques sécuritaires ont un cout, par exemple, si je souhaite assurer la disponibilité de mon système d’information, on peut par exemple développer un système totalement redondant de manière à ce que si un système tombe en panne on puisse en temps réel travailler sur le système redondant ; mais cela a un cout, il faut en permanence essayer de trouver le bon équilibre entre d’une part les couts de déploiement des mesures de sécurité, et d’autre part, l’impact en terme financier des risques pouvant survenir.

-‐ Dimension humaine : même si un système est techniquement bien sécurisé, il faut que les utilisateurs soient conscients et responsables des problèmes de sécurité. Par exemple : cela ne sert à rien de sécuriser à outrance un système si des utilisateurs peu fiables décident de leur propre chef de communiquer des informations à l’extérieur via d’autres moyens que le système en place.



-‐ Dimension managériale : finalement, déployer un projet de sécurité doit être géré, il y a donc une dimension managériale dans la sécurité parce qu’un projet de sécurité implique de nombreux acteurs, des budgets, des délais, etc. bref, tout ce qui fait un projet.

SECURITE DE LA BD = PROCEDURES + TECHNIQUES

METHODE DE GESTION DE LA SECURITE

Démarche générique pour déployer un plan de sécurité à partir d'une études des risques

Pour gérer la sécurité d’un système d’information, on part souvent d’une étude de risque qui répertorie les menaces sur, par exemple, la disponibilité ou la fiabilité de l’information. A partir de cette étude de risque on tente de mettre en place toute une série de contre-‐mesures pour essayer soit d’amoindrir la probabilité de survenance des risques ou encore, une série de mesures pour réagir en cas de survenance de ces risques.

Toutes ces mesures ou contre-‐mesures sont répertoriées dans ce qu’on appelle un plan de sécurité. Heureusement, pour guider les informaticiens et les gestionnaires dans la rédaction d’un tel plan de sécurité, il existe plusieurs approches disponibles dans la littérature.



Exemples :

-‐ CRAMM : CCTA Risk Analysis and Management Method développée par la Central Computer and Telecommunications Agency (CCTA) -‐ UK government agency

-‐ OCTAVE : Operationally Critical Threat, Asset, and Vulnerability Evaluation développée par la Computer Emergency Response Team (CERT) localisée à la Canergie Mellon University

-‐ EBIOS : Expression des Besoins et Identification des Objectifs de Sécurité développée par l'Agence nationale française de la sécurité des systèmes d'information -‐ http://www.ssi.gouv.fr/fr/bonnes-‐pratiques/outils-‐ methodologiques/ebios-‐expression-‐des-‐besoins-‐et-‐identification-‐des-‐objectifs-‐de-‐ securite.html

EBIOS (EXEMPLE)

EBIOS est une des méthodes dont on a parlé ci-‐dessus. Ce n’est pas la méthode la plus légère mais il est intéressant d’y jeter un coup d’œil.

STANDARDS

En plus de ces méthodes de gestion de la sécurité, il existe toute une série de réglementations et de normes qui peuvent soit contraindre les responsables de sécurité à atteindre un degré de sécurité fixé par ces réglementations ou normes, mais l’avantage de ces outils (réglementations ou normes) est aussi de suggérer un ensemble de contre-‐mesures typiques face à des problèmes de sécurité récurrents.

Notons que certaines réglementations sont orientées vers des secteurs d’activité, comme par exemple Bâle II, orienté vers la finance.



è Règlementations

-‐ prescrits légaux -‐ Sarbanes-‐Oxley, Bâle II, HIPAA, directives européennes

è Normes

-‐ développées par un organisme national ou international indépendant des industriels

-‐ Exemple : ISO 27002 : code de bonnes pratiques pour la gestion de la sécurité de l’information

EXEMPLE DE PROCEDURE DE SECURITE

Pour clôturer, nous allons voir un exemple concret de contre-‐mesure de sécurité.

CHOIX DE MOTS DE PASSE FORTS

Exemple de menace : un attaquant découvre un nom d’utilisateur et son mot de passe puis se connecte illégalement à un système d’information.

Par ce biais, l’attaquant peut avoir accès à des informations qui ne le concernent pas et qu’il n’aurait pas le droit de voir en temps normal, mais il peut aussi réaliser sous notre nom des actions inquiétantes, comme par exemple : commander et se faire livrer des articles que l’on devrait payer.

Cette menace est tout à fait réelle, par exemple avec certains systèmes comme ceux de gestion de BDD, qui sont installés par défaut avec des mots de passe standards, connus de tous ceux qui ont déjà installé ce système de gestion de base de données. Autre exemple : permutation des lettres du nom d'utilisateur

Autre manifestation de cette menace : des outils de soumission automatique de mots de passe naïfs : aujourd’hui sur internet il est très facile de trouver des logiciels qui tentent de s’identifier auprès de systèmes, de sites web à partir de listes standards de mots de passe, et ce n’est pas toujours très compliqué de connaître les noms d’utilisateur (soit l’e-‐mail, soit un numéro séquentiel, …) et donc la probabilité pour un attaquant de rentrer dans un système est malheureusement loin d’être nulle.



EXEMPLE DE MOTS DE PASSE NAIFS

Souvent, par facilité ou par naïveté, les utilisateurs consacrent peu d’efforts à choisir des mots de passe qui soient « forts ». Par exemple, dans la liste de droite, on retrouve une liste de toute une série de mots de passe que les utilisateurs choisissent régulièrement, qui sont connus, et qui peuvent être soumis par des outils de cracking automatique.

Autre exemple qui vient d’une plateforme e-‐learning bien connue : motdepasse, bidule, etc. qui sont des exemples tout à fait naïfs è ce n’est pas très compliqué de craquer des systèmes avec un niveau d’identification et d’authentification aussi faible.

EXEMPLE DE BETISE

Malheureusement, les utilisateurs ne sont pas toujours conscients des risques encourus lorsqu’ils laissent trainer sur leur bureau ou dans un tiroir une liste manuscrite de mots de passe. Imaginons par exemple un personnel de nettoyage mal intentionné, qui en quelques secondes pourrait trouver des informations d’identification tout à fait confidentielles.

Voici pour terminer, un exemple de quelques contre-‐mesures qui peuvent aider à parer la menace d’identification illégale



1. Première contre-‐mesure : imposer des mots de passe forts (devient très courant actuellement) è mots de passe forts qui respectent par exemple un certain nombre de règles en terme de mélange de chiffres/caractères, en terme de taille, etc. (èvariation dans la casse; mélange de chiffres, de lettres et de caractères spéciaux autorisés; 6 positions au minimum, etc.). On veillera aussi à modifier systématiquement les mots de passe installés par défaut par différents logiciels.

2. Deuxième contre-‐mesure : vérifier automatiquement la solidité des mots de passe choisis par les utilisateurs ; par exemple, en exécutant les outils bien connus qu’utilisent les pirates pour essayer de s’introduire illégalement dans des systèmes. è Exécution des outils des attaquants/ exécution d'outils dédiés à l'audit des mots de passe

3. Troisième contre-‐mesure : communiquer et responsabiliser l'utilisateur quant aux impacts de la sécurité des systèmes d’information, et lui donner à travers un plan de sécurité des lignes de conduite pour améliorer la sécurité du système è responsabiliser l’utilisateur quant à la confidentialité de ses données de connexion.



TABLE OF CONTENTS

PLAN 2

1. PROJET DE DEVELOPPEMENT D’UN SYSTEME D’E-‐BUSINESS 3

PROJET DE DEVELOPPEMENT E-‐BUSINESS 3 L’INGENIERIE LOGICIELLE : DEFINITION & DEMARCHE 3 1. PROCESSUS DE DEVELOPPEMENT 5 TYPES DE PROCESSUS 6 CONTREPIED DE LA PLANIFICATION : METHODES AGILE 7 PHASES & ACTIVITES TYPIQUES DE DEVELOPPEMENT 7 2. SPECIFICITES DES PROJETS E-‐BUSINESS 9 3. CYCLE DE DEVELOPPEMENT D’UN LOGICIEL 11 CYCLE DE DEVELOPPEMENT EN CASCADE 11

2. LANCEMENT DU PROJET 16

1. DEFINITION DE LA PORTEE DU SYSTEME E-‐BUSINESS 17 2. GESTION DES ACTEURS 19 3. GESTION DE PROJET 22 RESULTAT SOUS CONTRAINTES 22 TECHNIQUES DE PLANIFICATION 23 ETUDE DE CAS : SPORTS D’HIVERS 24

3. ETUDE D’OPPORTUNITE 29

1. RETOURS D’UN SYSTEME 29 RENTABILITE D’UN PROJET DE DEVELOPPEMENT 29 RETOUR SUR INVESTISSEMENT : COUTS 30 RETOUR SUR INVESTISSEMENT : BENEFICES 31 2. FAISABILITE D’UN PROJET 32 FAISABILITE FACE AU RISQUE 33 3. EVALUATION DU COUT D’UN SYSTEME 34 ESTIMATION DES COUTS DE DEVELOPPEMENT 34 ANALYSE PAR POINTS DE FONCTION (FP) 35 PARAMETRES 37 CONVERSION EN LIGNES DE CODE 40

4. SPECIFICATIONS 50

1. DEFINITION DE LA SPECIFICATION 50 DIMENSIONS CONSTITUTIVES 51 TYPES DE BESOINS 52 TYPES DE SPECIFICATIONS 52 UML ET RUP 54 2. DIAGRAMME DE CAS D’UTILISATION 56 EVALUATION DES CAS D’UTILISATION 65 DEMARCHE DE CONSTRUCTION 65 GRANULARITE DES CAS D’UTILISATION 66 3. DIAGRAMME D’ACTIVITE 76 DIAGRAMME D’ACTIVITE (UML1.*) 76 ACTION & FLUX DE CONTROLE 77



NŒUDS DE CONTROLE 78 PARTITION 82 DETAIL DES ACTIONS 82 EXTENSION DES DIAGRAMMES D’ACTIVITE UML 2.0 85 OBJECT FLOWS 86 INTERRUPTIBLE ACTIVITY REGION (UML 2.0) 87 EXPANSION REGION (UML 2.0) 88 WAIT TIME ACTION (UML 2.0) 89 ERREURS FREQUENTES 89 DIAGRAMMES D’ACTIVITE ET SITES WEB 90 DETAIL DE PAGE APPLICATIVE 92 EXERCICES 92 4. DIAGRAMME DE CONTENU 94 5. DIAGRAMME D’INTERFACE 96 6. ETUDE DE CAS 98

5. REALISATION 105

1. CONCEPTION ET MISE EN ŒUVRE 105 CONCEPTION 105 MISE EN OEUVRE 107 2. OUTILS DE DEVELOPPEMENT 108 OUTILS DE DEVELOPPEMENT CLASSIQUES 108 GENERATEURS DE SITES 110 PACKAGE ET CONTENT MANAGEMENT 111 3. TECHNIQUES CLES 114 PAGES DYNAMIQUES 114 INTEROPERABILITE DES SYSTEMES 117

6. MISE EN PRODUCTION 122

ACQUERIR UN NOM DE DOMAINE 122 HEBERGEMENT D’UN SITE 123

7. TEST 125

QUALITE D’UN SYSTEME E-‐BUSINESS A TESTER 125 TESTS AUTOMATIQUES 126 DELEGATION DE TESTS MANUELS 127 RETOUR E-‐BUSINESS 128

8. EXEMPLE : RATIONAL UNIFIED PROCESS 130

ORGANISATION DU RUP DANS LE TEMPS 130 DISCIPLINES 131 RUB « BEST PRACTICES » 132

9. MAINTENANCE ET PROMOTION 134

MAINTENANCE 134 PROMOTION 135 LA PROMOTION D’UN SITE WEB COMMERCIAL 135 REFERENCEMENT DANS LES MOTEURS DE RECHERCHE 136 E-‐MAILING DIRECT 138



PUBLICITE – BANNERING 139 MISE EN PLACE DE PARTENARIATS 140 RELATIONS PUBLIQUES EN LIGNE 141

10. SECURITE 142

ETAT ET ENJEUX 142 L’ETAT DES SYSTEMES 142 AMPLEUR DU PHENOMENE 147 ENJEUX DE LA SECURITE 147 DIMENSIONS CLES DE LA SECURITE 147 SOLUTIONS 148 APPROCHE MULTIDIMENSIONNELLE DE LA SECURITE 149 SECURITE DE LA BD = PROCEDURES + TECHNIQUES 150 METHODE DE GESTION DE LA SECURITE 150 STANDARDS 151 EXEMPLE DE PROCEDURE DE SECURITE 152 CHOIX DE MOTS DE PASSE FORTS 152

e-business - développement

Documents