Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Get this document free

2265U04 – Langage Java

VIEWS: 26 PAGES: 31

									2265U06 – Informatique professionnelle
M. Paul Angevelle http://paul.angevelle.free.fr

Le cycle de vie du logiciel - les phases, les acteur
2007-01-08 Quelques chiffres préliminaires 25% des projets respectent les délais et les budgets 45% dépassent le budget ou sont en retard 30% sont abandonnés ou voient leur périmètre très largement restreint Combien correspondent à des besoins utilisateurs réels ? L’objectif Un logiciel qui :  Répond au besoin des utilisateurs  Est développé dans le respect des délais et du budget  Est maintenable  Est évolutif  Est documenté  Est testable Les facteurs d’échec  Le manque de communication Rq : entre les différents intervenants. parfois, même des refus de communication  Une mauvaise compréhension des besoins réels  La mauvaise formation des personnes Rq : MOA doit former les personnes.  Le cadre contractuel inadapté  L’insuffisance des tests Rq : pour respecter le délai, on s’en passe souvent la phase de tests et l’éditeur compte sur les tests d’utilisateurs et corrige plus tard des bugs remontés.  L’absence d’une démarche « Thing Big – Start Small » Rq: on commence tjs du petit et  Les effets Tunnel Rq : un informaticien se ?

Le cycle de développement - les acteurs
 Part d’une version « n » et livre une version « n+1 »

1



Met en œuvre au conrs des différentes étapes :  Des méthodes  Des acteurs  Des outils

Les acteurs  Maîtrise d’ouvrage (MOA) :  Conçoit les aspects fonctionnels  Recette les livraisons  Maîtrise d’œuvre (MOE) :  Conçoit les aspects techniques  Réalise le logiciel  Comité de pilotage :  Réalise la jonction entre MOA et MOE  Dirige le projet

La MOA  Recueille et analyse les besoins utilisateurs  Définit le fonctionnel de l’application  Fournit le cahier des charges fonctionnel (spécification fonctionnelle détaillée) Ex : quel bouton déclenche telle opération  Recette la (les) livraison(s)  Répond à la MOE tout au long du projet

La MOE  Réceptionne le cahier des charges  Définit l’architecture  Ecrit les spécifications techniques  Développe  Fait les tests unitaires et d’intégration Rq : les « tests unitaires » sont des tests spécifiques pour une certaine fonctionnalité du projet.  Livre à la MOA le produit final

Le comité de pilotage  Composé d’une personne de chaque métier  Arbitre les demandes de la MOA par rapport aux contraintes de la MOE  Garant des délais et de l’adéquation aux besoins

Le cycle de développement - les étapes, les modèles classiques, les méthodes agiles
Les phases  Etude de faisabilité Rq : « est-il faisable avec le budget affecté et le délai demandé ? » 2

     

Spécifications Développement Contrôles Essais Validation Vente / utilisation / entretien Rq : « entretien » => le logiciel sans bugs n’existe pas.

Analyse des besoins et faisabilité Spécifications Conception architecturale Conception détaillée Codage Tests de validation Installation

Les méthodes classiques Le cycle en cascade  Chaque étape est validée Rq : toute étape fait l’objet des documentations qui nécessitent une validation, ce qui permet de passer à l’étape suivante.  Produit des livrables définis au préalable  Se termine à une date précise Rq : le projet est « censé » se terminer à une date précise. En effet, tout dépend des validations des étapes précédentes.  Ne se termine que lorsque les livrables sont jugés satisfaisants lors d’une étape de validation - vérification

Le cycle en V  Amélioration du cycle en cascade (meilleure réactivité aux anomalies)  Basé sur le principe d'anticipation et de préparation lors des étapes descendantes des "attendus" des futures étapes ascendantes  Standard de l'industrie du logiciel depuis les années 80

Le cycle en spirale  Le développement reprend les étapes du cycle en cascade  Aboutit au produit final par itérations successives  Bien adapté aux projets risqués (peu de nouveau code à chaque itération)

3

La méthode par incrément  Chaque incrément implémente un des cycles décrits précédemment  Un noyau est développé au préalable  Un ou quelques composants du logiciel sont développés ET intégrés (à chaque incrément) au noyau et aux incréments précédents

Unified Process  « méhtode » générique  Itérative et incrémentale 4



Basée sur les outils et méthodes (UML …) et la documentation

En résumé  Adaptés à tout projet informatique  Adapté à toute entreprise (management classique)  Garantissent la qualité et l’adéquation aux besoins du logiciel fournit  Délais et contenu maîtrisés

Mais…  Process peu réactifs  Gros besoin d’anticipation  Le coût de l’erreur est très important  Coût organisationnel important

Les méthodes agiles - les valeurs, eXtrem Programming, Scrum
Quelques méthodes agiles  eXtrem Programming (XP)  Scrum  Test Driven Development  Feature Driven Development  Rapid Application Development  Adaptive software development  Crystal clear  …etc !

Les valeurs  L’équipe (« Personnes et interaction plutôt que processus et outils »)  L’application (« Logiciel fonctionnel plutôt que documentation complète »)  La collaboration (« Collaboration avec le client plutôt que négociation de contrat »)  L’acceptation du changement (« Réagir au changement plutôt que suivre un plan »)

eXtrem Programming 4 valeurs fondamentales :  Communication  Simplicité  Courage  Feedback

eXtrem Programming (suite) :  Revue de code permanente (principe du binôme)

5

       

Test développés avant les fonctionnalités Refactoring continu Choix de la solution la plus simple Communication par métaphores Intégration continue Cycles de développement très rapides Client sur site Responsabilité collective

Scrum  Processus itératif basé sur des « sprints » courts (30j max)  Chaque sprint amène à une livraison fonctionnelle décidée en début de sprint  Pas de tache de plus de 2 jours  Les taches ne sont pas affectées à l'avance mais « au fil de l'eau »  Le client est libre de modifier le contenu fonctionnel qui n'est pas inclus dans le lot du sprint en cours (ni déjà développé)  L'équipe est auto gérée Les acteurs  Le directeur de produit (= le client) : définit la priorité des fonctionnalités attendues.  L'équipe : autogérée, sans rôles prédéfinis ni hiérarchie  Le Scrum master : protège l'équipe, garant de sa tranquillité (gère l'administratif, les reportings ...)  Les intervenants : Extérieurs qui souhaitent suivre le projet (hiérarchie, experts techniques ...) Rq : ils peuvent assister aux réunions, mais pas droit à la parole.
Projet Release
sprint sprint sprint

Release
sprint sprint sprint

Produit partiel, testable et utilisable

Produit partiel, déployable

Produit final

En résumé 6

  



Beaucoup de souplesse dans la définition fonctionnelle Rq : on ne connaît pas à l’avance où l’on va. On fait les choses au moment où l’on en a besoin. Basé sur le constat : un bon logiciel est un logiciel qui fonctionne process basés sur la communication et la culture d'équipe. Donc pas plus de 20 personnes dans l'équipe Rq : il y a très peu de documentations, même pas du tout. Tout se base sur la communication de l’équipe. En général, on se trouve dans la même pièce et se parle entre eux. Cela marche pour moins de 20 personnes (au delà, on devrait revenir aux démarches de validation). Attention à la fausse agilité !

L’agilité est plus que la mise en œuvre d'une méthode  Hiérarchie adaptée : il n'y a pas en début de projet de planning et budget précis.  Etat d'esprit : méthodes basées sur l'équipe. Dont fait partie le client.  Environnement favorable : pas d'appel téléphoniques trop fréquents, de réunions incessantes, d'irruptions dans la pièce de l'équipe, d'opérations urgentes ...  Et surtout : Pas d'heures supplémentaires pour les équipes !

Les outils - Gestion de configuration, suivi de projet, gestion des bugs…
Gestion de configuration Logiciel « CVS »

7

8

Rq : on peut garder toutes les versions successives avec les informations nécessaires (l’auteur de modification, la modification, etc.). Tests

Intégration

9

Rq : l’intégration continue permet de passer des tests régulièrement et de s’assurer que les nouvelles modifications n’ont pas pour effet de remettre en cause les travaux précédemment validés, ce qui arrive souvent. Suivi de projet « Diagramme de Gant »

10

Gestion de documentation

« Wiki »

11

Suivi des bugs

Rq : il y a plusieurs niveaux de gravité du bug :  « bloquant » Rq : c’est le bug qui empêche l’utilisation du logiciel

12

 

« majeur » Rq : c’est un bug « bloquant » dont on a un moyen de le contourner dans l’utilisation « mineur »

Quelques erreurs classiques - Gagner du temps, de l’argent…
Gagner du temps  Les spécifications : « écrire des documents prend trop de temps »  La documentation : (idem)  Augmenter la taille de l’équipe : « à deux, vous irez deux fois plus vite » Rq : tout n’est pas parallélisable. De plus, plus l’équipe est nombreuse, plus il aura des problèmes de communication entre eux.  Imposer des délais irréalistes

Rattraper du temps Augmenter la taille de l’équipe en fin de projet : « En ajoutant des membres à l’équipe, le délai sera tenu » Rq : il faut bcp de temps pour se mettre dans le bain. Gagner de l’argent

13

   

Equipe sans expérience : « Je vous ai trouvé des stagiaires ! » Ajout de fonctionnel : « J’ai vendu une nouvelle fonctionnalité » Rq : avant de la vendre, il faut avoir demandé des avis des experts sur la réalisabilité de la nouvelle fonctionnalité et son impact sur l’architecture déjà existante. Respecter le contrat ! : « Je sais que ça n’a aucun sens, mais c’est dans le contrat » Economiser sur les outils : « On va faire le suivi de projet avec Excel »

En faire trop  Syndrome du plaqué or : « C’est compliqué, ça n’apporte rien, mais on y tient »  Modification de l’existant : « On n’a pas entamé le principal, mais il faudrait faire des évolutions mineures sur l’existant »  La corne d’abondance : « Tu viens de finir une fonctionnalité, j’en ai trois nouvelles pour toi »

Sous estimer la charge  Oubli du temps de communication (n personnes => n  (n  1) )  Spécification trop simple : « J’ai spécifié le cas général »  Oubli du principe 80/20 : « Visiblement c’est presque fini »  Oubli de la formation des juniors, du temps de recherche, des expérimentations

Architecture des logiciels - l’architecture ?
L’architecture physique  Exécutable indépendant  Power point  Client serveur  Sites Internet  Intranet  Jeux en ligne  Mail  Réseau de clients  eMule

Architecture des logiciels - les clients
Exécutable indépendant  Architecture la plus simple, très utilisée avant la montée en puissance d’Internet  Le logiciel vit sur un ordinateur déconnecté  Communication éventuelle entre les utilisateurs via des fichiers  Adapté aux logiciels destinés à un travail solitaire et ne nécessitant pas de ressources extérieures

14





Des avantages :  Pas de serveur à maintenir  Simple à programmer (pas de programmation réseau)  Pas de problématiques de sécurité Et des inconvénients :  Pas de maîtrise des versions utilisées, mise à jour pénible Rq : c’est un facteur qui génère des charges très lourdes.  Pas de maîtrise des configurations Rq : l’utilisateur ne maîtrise pas les configurations sur leurs PC.  Pas de maîtrise de l’environnement logiciel et matériel

Client Serveur

Réseau de clients

Le client léger  Matériel ou logiciel  « Ordinateur » sans disque dur  Navigateur Internet  Ne contient presque pas de logique applicative  L’application s’exécute entièrement sur le serveur

15





Des avantages :  Déploiement des nouvelles versions très simplifié  Maîtrise de la version utilisée par le client et de sa configuration (= simplification de la maintenance)  Quasiment indépendant de l’environnement logiciel et matériel de l’utilisateur  Architecture « claire » et compréhensible par tous => peu d’erreurs grossières de programmation Et des inconvénients :  Limitations techniques de l’interface graphique  Utilisation du réseau intense et impérative  Forte utilisation du serveur  Problèmes de niveau de sécurité du client  Javascript  Accès au système de fichiers  …  Sécurité des transactions client  serveur Rq : pour certains systèmes, un package minimal suffit pour contourner les mécanismes de sécurité.  Compétence des administrateurs  Pas de communication entre clients

Le client lourd  Logiciel complet  Contient une partie de la logique applicative  L’application s’exécute partiellement sur le serveur et partiellement sur le client  Des avantages :  Pas de limitations techniques :  Maîtrise parfaite du comportement  Parallélisation de tâches  Communication entre clients  Accès au système de fichiers  …  Utilisation réduite du réseau et du serveur  Compétence des administrateurs moins nécessaire  Peut éventuellement être déconnecté du serveur  Et des inconvénients :  Déploiement des nouvelles versions  Pas de maîtrise de la version utilisée par le client => compatibilité ascendante du serveur  Pas de maîtrise de la configuration client  Pas de maîtrise du poste client (OS, Firewall, …)  Problème de la sécurité du poste client  Architecture plus complexe => « où doit je mettre mon code »

Le mutant : RIA (Rich Internet Application) Les principaux avantages des deux types de client :  Pas de déploiement complexe  Une UI interactive

16

RIA : les technologies  XHTML + Javascript + CSS Exemple du HTML : <HTML> <BODY> <P> du texte <BR/> <I> italique </I> </P> <P> un autre paragraphe </P> </BODY> Rq : « <BR/> » => point à la ligne (càd « Entrée ») « <P> » : début du paragraphe ; « </P> » : fin du paragraphe  Java (Applet, Java Web Start)  AJAX (Asynchroneous Javascript And XML)  Flash  Windows vista + XAML L’avenir  Clients RIA  Intégration dans les logiciels existants (Web services integer dans Outlook)  Clients lourds mis à jour automatiquement  Utilisation des frameworks « Java »/ « .Net »

Architecture des logiciels
- les serveurs Les serveurs  Gère tout ou partie de l’application  Sécurisé derrière un firewall  Souvent organisé en ferme de serveurs  Serveurs web  Serveurs d’application (métier)  Souvent connecté à une / des bases de données  Dns un environnement maitrisé

17

Les stockage des données  Fichier enregistré sur le PC client  Données persistantes  Sans mise à jour : base de données, fichiers texte, XML  Avec mise à jour : base de données  Données temporaires  Fichiers temporaires  Session web  Cookies Le format XML  Norme apparue en 2000  Découle de la nécessité de différencier contenu et présentation  Contient exclusivement des données organisées  Beaucoup de possibilités de traitement grâce à une batterie d’outils (XSD, XSL, CSS)  Beaucoup de langages intègrent des parseurs XML => forte utilisation

18

Comparaison : <PRICE> <OriginAmount> 192 </OriginAmount> <OriginCurrency> EUR </OriginCurrency> </PRICE> Ou <PRICE OriginAmount = 192 OriginCurrency = EUR />

19

XSLT : schéma de principe

Exemple : XSLT

Les bases de données  Des possibilités de stockage gigantesques (plusieurs millions d’entrées par table)  Des liaisons relationnelles entre les tables  Un langage unifié de requêtage : SSL  Des lectures / mises à jour des données très optimisées 20

 

Une intégration dans tous les langages Des données typées

Une représentation sous forme de tables  Une relation entre les tables



Un langage de requête (SQL)  Select * from personne  Select personne.nom from personne, ville where ville.nom = ‘Paris’ and ville.cide = personne.ville_naiss  Delete from personne where nom like ‘z%’

Les bandes magnétiques  Permet de sauvegarder des données en grand nombre  Stockage de sécurité (sauvegarde des données vitales de l’entreprise)  Envite le dépôt de bilan en cas de crash d’un disque dur…

Architecture des logiciels
- des logiciels comminicants Les protocoles propriétaires  Rien n’est normalisé => tout est à coder et à maintenir  Souvent dus à un long historique  Tendent à disparaître Les API  Souvent basées sur des normes existantes (HTTP, TCP/IP…)  Définissent leur propres norme « d’encodage » des données  Nécessitent d’écrire et maintenir les encodeurs et parseurs COM, DCOM  Protocole propriétaire Microsoft  Permet au « serveur » d’exposer des objets (données + méthodes) à des clients  Obsolète depuis l’arrivée de « .NET » Les Web services  Echange de données entre un fournisseur et un consommateur  Entre un fournisseur et un intégrateur  Entre un client lourd et un serveur  Souvent XML + HTTP

21

 

Forte intégration par les langages majeurs (utilisation transparente pour le développeur) Commencent à apparaître dans les logiciels courants

Architecture des logiciels
- l’architecture logique L’architecture 3 tiers  Couche de présentation :  Transmet les actions de l’utilisateur vers les couches métiers  Affiche les résultats obtenus par la couche métier  Logique métier :  Traite les requêtes  Applique les règles métiers sur les données de la base  Accès au données :  Gère les connections à la (aux) base(s)  Transforme le SQL en objets La couche de présentation  Partie visible de l’application  Sert d’interface entre l’utilisateur et la couche métier  Peut être modifiée sans changer la finalité de l’application  Affichage différent : Flash, HTML, …  Restriction de fonctionnalités La couche Métier  Implémentation de la logique applicative  Reçoit les demandes de l’IHM  Demande les données à la couche d’accès aux données  Applique les règles métier  Renvoit les résultats à l’IHM C’est la couche à forte valeur ajoutée La couche d’accès aux données  Fournit les données à la couche métier  Fait une abstraction au dessus des systèmes de stockage (= couplage faible entre métier et stockage)  Peut masquer un système tiers  Gère la Base de données  Gère la connectivité aux bases  Gère la répartition des requêtes entre bases  Peut gérer une persistance en mémoire  Gère la transformation des requêtes de la couche métier en SQL et la réponse de la base en objet

22

L’architecture 3 tiers  Permet une séparation claire des taches en terme de programmation  Définit un contrat entre deux couches. Tant que ce contrat ne change pas, une des deux couches peut être modifiée librement  Permet éventuellement de séparer les couches physiquement (meilleure utilisation des ressources serveur) L’architecture 3 tiers « orientée services »

23

2007-01-22

Les technologies - les langages
         Assembleur Fortran Cobol C++ Javascript PHP Delphi Java, .Net BrainF*ck, Ook

Assembleur  Langage machine « compréhensible » par un humain  Actions sur la mémoire (physique) directement par le programmeur  Spécifique à l’environnement matériel  Permet les optimisations de parties de code ou le débuggage  Difficilement maintenable Exemple : .model small .stack 100h .data bonjour db "Hello world!$" .code main proc mov AX,@data mov DS, AX mov DX, offset bonjour mov AX,0900h int 21h mov AX,4C00h mov 21h main endp end main

Fortran  IBM Mathematical FORmula TRANslating System  Langage ancien (1956), toujours utilisé pour les calculs scientifiques  Execution très rapide  Fortement typé  Langage procédural (devenu objet en 2003) Exemple :

24

Cobol  Langage ancien (1960)  Simple, auditable pas un non informaticien  Très bonne gestion des virgules et des calculs => très utilisé (banque …)  75 % des programmes du monde des affaires … Un langage simple à écrire :

C++  Evolution orientée objet du C (1985)

25

 programmation objet ou procédurale (compatibilité des programmes C)  classes,  encapsulation,  surcharge d’opérateurs,  template (programmation générique),  gestion d’exceptions,  espaces de nom  Rapide  Relative facilité de programmation  Des compilateurs pour quasiment toutes les plateformes !  Très souple Mais …  Une compilation par système cible  Programmation de la UI pénible  Pas de gestion de la mémoire  Trop souple

Javascript  Langage interprété utilisé principalement en complément de HTML (DHTML, Web2.0)  Langage de script client  Faiblement typé  Pas d’accès aux fichiers  Peut être intégré pour scripter une partie d’une application Exemple supplémentaire N°1 : …\Info professionnelle\Info Pro_4_PA\Technologies-Exemples\compteur.html Code : <HTML> <Head> </Head> <Boby> <script language="javascript"> function countCharacters(target){ target.form.compteur.value=target.value.length; }

26

</script> <form name=form> <textarea onKeyDown="countCharacters(this)" rows="4" cols="22"></textarea><br> <input name="compteur" type="text"/> </form> </html> Exemple supplémentaire N°2 : …\Info professionnelle\Info Pro_4_PA\Technologies-Exemples\visibility.html Code : <html> <head> <script language="Javascript"> function bascule(elem) { etat=document.getElementById(elem).style.visibility; if(etat=="hidden") { document.getElementById(elem).style.visibility="visible"; } else { document.getElementById(elem).style.visibility="hidden"; } } </script> </head> <body> <input type="button" onClick="bascule('boite');" value="On/Off"> <div name="boite" id="boite" style="visibility: hidden"> <form> <input type=text value="Coucou, je suis là"> </form> </div> </body> </html>

PHP  Langage de script serveur  Gère les connections aux base de données  Génère du HTML  Gratuit  Adapté aux petits projets Web Exemple supplémentaire : …\Info professionnelle\Info Pro_4_PA\Technologies-Exemples\hello_world.php

27

Code : <html> <head> <title>Hello World</title> </head> <body> <?php echo "Hello world"; ?> </body> </html> Rq : le code (< ? … ?>) disparaît lorsqu’on affiche la source à partir de la page Web affichée Delphi  Pascale objet. Simple et rigoureux  Quelques limitations (héritage multiple, surcharge d’opérateurs …)  Mémoire non managée  Excellent outil RAD ! Exemple supplémentaire : …\Info professionnelle\Info Pro_4_PA\Technologies-Exemples\thread\Project1

Java / .Net  Plus qu’un langage : un framework complet  Langages riches en fonctionnalités  Gestion automatique de la mémoire  Portabilité du code généré Java / .Net - des framework complets  Connection aux bases de données  Gestion transparente du XML  Communication facilitée entre les programmes (ou les tiers du programme)  De nombreux outils Java / .Net - des langages riches  Programmation générique  Nullable types (.Net)  Programmation Internet facilitée  Reflection  Auto boxing Rq : transformation automatique d’un objet à un autre en fonction de besoin.  Programmation déclarative  Enumérations  Interfaces Java / .Net - la gestion de la mémoire

28

 

Le framework gère la libération des objets. Tant qu’un objet est utilisable, il est conservé en mémoire. Évite les fuites mémoire et les écrasements mémoire => stabilité accrue, pas de débuggage difficile.

Java / .Net - la portabilité  Le « code » généré à la compilation n’est pas du code machine  Pour chaque équipement spécifique un « interprète » (machine virtuelle) est fournit qui va faire la liaison entre le code et la mémoire Exemple « .Net » : « Microsoft Studio »

BrainF*ck / Ook  Langages minimalistes mais complets composés de 8 instructions  Basé sur la machine de Turing  Manipulation d’un pointeur sur une zone mémoire (déplacement, addition, lecture/écriture, boucle)  Et un compilateur de 171 octets … Ook > incrémente (augmente de 1) le pointeur. < décrémente (diminue de 1) le pointeur. + incrémente l'octet du tableau sur lequel est positionné le pointeur (l'octet pointé). décrémente l'octet pointé. . sortie de l'octet pointé (valeur ASCII). , entrée d'un octet dans le tableau à l'endroit où est positionné le pointeur (valeur ASCII). [ saute à l'instruction après le ] correspondant si l'octet pointé est à 0. ] retourne à l'instruction après le [ si l'octet pointé est différent de 0. Brainfuck > < + . , [ ] C ++ptr; --ptr; ++*ptr; --*ptr; putchar(*ptr); *ptr = getchar(); while ((*ptr) != 0) { }

« Hello_World » en Brainfuck : BrainF*ck ++++++++++ [ >+++++++>++++++++++>+++>+<<<<] >++. 'H' >+. 'e' +++++++. 'l' 29

. 'l' +++. '0' >++. espace <<+++++++++++++. 'W' >. 'o' +++. 'r‘ ------. 'l' --------. 'd' >+. '!' >. nouvelle ligne

Ook Ook. Ook? incrémente (augmente de 1) le pointeur. Ook? Ook. décrémente (diminue de 1) le pointeur. Ook. Ook. incrémente l'octet pointé. Ook! Ook! décrémente l'octet pointé. Ook. Ook! sortie de l'octet pointé (valeur ASCII). Ook! Ook. entrée d'un octet dans le tableau à l'endroit pointeur (valeur ASCII). Ook! Ook? saute à l'instruction après le Ook? Ook! l'octet pointé est à 0. Ook? Ook! retourne à l'instruction après le Ook! Ook? si différent de 0.

où

est

positionné

le si est

correspondant l'octet pointé

« Hello_World » en Ook : Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook. Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook. Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook. Ook! Ook. Ook! Ook? Ook! Ook! Ook? Ook! Ook. Ook. Ook. Ook.Ook. Ook.Ook. Ook.Ook. Ook.Ook. Ook.Ook. Ook.Ook. Ook.Ook. Ook.Ook. Ook. Ook! Ook.

Les technologies - choisir une technologie

30

Gérer l’existant  Principe de base : Conserver au maximum l’existant  Quel plateforme pour le nouveau code ?  Quelles capacité de communication entre ancienne et nouvelle technologie ? Gérer les personnes  L’équipe de développement :  Besoin de formation  Motivation  Attention au marché de l’emploi …  Le management :  Est-ce que ça apporte quelque chose ?  Les équipes d’administration et de maintenance :  Besoin de formation  Remise en cause des habitudes et des méthodes de travail Choisir…  En fonction du besoin !!!  En fonction de l’environnement  Des technologies homogènes  Java / Linux / Oracle  .Net / Windows / SQL Server  PHP / Linux / MySQL Exemple : Un client serveur sans charge excessive et sans gros fonctionnel métier => PHP Un utilitaire sans BDD, standealone, à usage interne => Delphi Un logiciel temps réel => Fortran / C++ Un client / serveur avec client léger + export de Web services => .Net / Java

31


								
To top