Du développement d'une application à la mise en production

Introduction

Des phases et des environnements différents

La phase de développement

La phase de préproduction

Le cas des progiciels

La phase de production

La phase de maintenance

En matière de conclusion : Le système des informations et la gouvernance

Introduction

Le but de cette présentation est d'aborder concrètement, dans le contexte de l'entreprise, les principales étapes et processus de mise en production d'une application et de ses données, de sa phase de développement jusqu'à sa maintenance.

Ou comment intéger un programme et des données à un environnement industriel.

Les objectifs visés :

un SI efficace, fiable et maîtrisé
un SI de qualité, et donc orienté service à l'utilisateur

Cela veut dire , pour les développeurs et administrateurs que nous sommes, dépasser la satisfaction d'avoir écrit un programme qui répond aux exigences fonctionnelles des spécifications détaillées,
voire simplement, d'avoir réussi à écrire un programme qui fonctionne ;-)

Exemples centrés sur les bases de données et les applications web.

Des phases et des environnements différents

Dans le cycle de vie du SI il existe un certain nombre de phases distinctes, nous nous focaliserons sur 4 d'entre elles

spécifications
developpement
recettes fonctionnelle et technique
tests
production,
maintenance

a l'issue de chaque phase, on devra obtenir les documents, scripts, programme nécessaires au passage à la phase suivante. En ce qui nous concerne, par exemple outre le programme développé, tous les éléments permettant le passage en préproduction.

Un peu plus dans le détail nous pouvons présenter un exemple concret objectifs et livrables de chaque phase :

Étapes	Objectif	Livrables
Expression des besoins	Rassembler et formaliser les besoins dans un domaine technique ou fonctionnel	Dossier d’expression des besoins Cahier des Charges
Étude d’opportunité	Étudier et formaliser les éléments nécessaires à la prise de décision sur le lancement ou non d’un projet	Dossier d’Étude d’opportunité
Conception	Étudier du général vers le détaillé les spécifications de la solutionÉventuellement maquetter	Dossier d’étude préalable, Dossier d’étude détaillée Dossier d’Architecture Dossier de Description des Données, Dossier d’étude technique
Planification	Mettre en place le projet : organisation de l’équipe, des moyens matériels et humains,Définition des tâches, élaboration des plannings	Planning du projet Organisation de l’équipe de réalisation
Développement	Construire la solution retenue selon les spécifications validées	Programmes, Scripts de création du schéma BD, des shell scripts Dossier d’installation, Procédures arrêt redémarrage de l’application Descriptions des traitements différés (batchs)
Tests, Recette, préproduction	Valider la conformité de la solution construite et de sa capacité à la mise en production	Plan de tests Dossier d’Architecture Cahier des contraintes techniques Description des Données Consignes d’exploitation
Mise en œuvre	Installer et déployer la solution recettée	Dossier d’installation
Exploitation	Surveiller, Administrer les comptes et les système, Sauvegarder, Épurer, Archiver, Exécuter les travaux différés, Déceler les incidents de production	Journal de Bord Consignes et modes opératoires (sauvegardes, restauration, redémarrage, reprise après panne, ...)
Maintenance	Prise en compte des anomalies et demandes d’évolutions Mesure de la performance et controle qualité	Suivi des anomalies et demandes d’évolutions Tableau de bord

les environnements associés

On aura 3 environnements (plus ou moins) distincts pour passer du développement, au test et à la mise en production :

poste / serveur / base / schéma de dev
poste / serveur/ base / schéma de pre prod
poste / serveur/ base / schéma de prod

architecture 'idéale'

architecture minimale

l'architecture 'idéale' est une architecture à 3 tiers, la minimale à 2 tiers (base locale au serveur)
on pourrait imaginer une architecture minimaliste (à bannir) : srv de DEV = srv de TEST = srv de PROD

spécificités des environnements

Chaque environnement est spécifique en terme de charge, de ressources, de standardisation, de disponibilité, de niveau de sécurité, ou de qualité de service du manière générale. C'est surtout pour cela qu'il est nécessaire d'avoir des environnements distincts.

		ressources	charge USER	disponibilité	confidentialité / intégrité
DEV	poste serveur BD	****** * / ***	- * **	*	* ** *
TEST	poste serveur BD	*** *	- ** **	*	* ** *
PROD	poste serveur BD	* ** **	- ****** **	* ** **	** **

Du fait de cette hétérogénéité du SI, standards et normes sont très importants. En production bien sûr pour des raisons d'efficacité, mais entre les 3 environnements, pour éviter les problèmes d'incompatibilité.

quelques exemples de spécificités

postes / serveurs de DEV
puissance CPU, ressources RAM et disque
problèmes de compatibiliés des différentes environnements (exemples WareHouse Builder, Designer ou V8/V9/10)
serveurs / bases de TEST
'instables'
est susceptible d'être rebooté fréquemment pour prendre en compte des paramètres statiques par exemple, ou suite à un 'plantage'.
volumineux
test de charge ==> volume , 1 base ou srv de tests ==> agrégation des données de prod
serveurs / bases de PROD
disponibles
voire hautement disponible si internet ou extranet
accès intéractif ou batch
problème de ressource (Rollback segments, segments temporaires et undo tablespaces, archive logs)
problème de planification (baseS et serveurS dispo pour les batchs ?)

une dérive classique, consiste à recopier les bases de PROD dans la base de TEST, voire dans la base de DEV. Cela évite d'avoir à produire un jeu d'essai (pertinence parfois complexe à réaliser) ou d'initialiser le schéma lors du développement d'une nouvelle version.
Effet pervers : plus aucune confidentialité, des volumes totalement superflus

La phase de développement

Développer un programme fonctionnellement satisfaisant n'est pas suffisant (d'où l'utilité d'une recette technique en plus de la fonctionnelle)
Outre le développement du programme dans un langage donné il existe un certain nombre d'outil logicies complémentaires, parfois intégrés au sein d'un logiciel complexe

Ne pas mélanger les genres

Bloc note Windows (Vi Unix !!!!!) <> Studio ... y compris pour PHP <> Frontpage / Dreamweaver
contenu dynamique <> contenu statique
structure <> présentation <> code
langage de programmation <> SQL, HTML

Utiliser des ateliers de génie logiciel complets ou des utilitaires additionnels pour développer, qui permettent de :

modéliser (Oracle Designer)
gérer les versions (CVS, Source Forge)
collaborer,
documenter (javadoc, PHPDoc, Comment SQL)
rétro documenter () (Oracle Designer, AMC Designer)
générer du code
- JDevelopper : JAVA
- Oracle WebDB : PL/SQL
- PHPMyadmin / Oracle ENterprise Mananger : SQL
- DreamWeaver : HTML , CSS ET SQL !

exemples de livrables spécifiques BDs

Ils peuvent revétir différentes formes : Shells, SQL, .bat

exemples de scripts SQL

exemple de script général

-- cr_schema.sql
spool ian_log
@@cr_tab.sql
   @@cr_dblink.sql
   @@cr_view.sql
   @@init_data.sql
   @@cr_syn.sql
   @@cr_pack.sql
   @@cr_fonc.sql
   @@cr_proc.sql
   @@cr_seq.sql
   @@cr_trig.sql
-- execution d'une procedure stockée
   DECLARE 
   RETOUR NUMBER;
   BEGIN 
   RETOUR := NULL;
   MAJ_ANNUAIRE ( RETOUR );
   DBMS_OUTPUT.Put_Line('RETOUR = ' || TO_CHAR(RETOUR));
   COMMIT; 
   END; 
   /
-- verif
   SELECT COUNT(*) FROM t_ANNUAIRE;
-- fermeture des logs
   SPOOL OFF

exemple de scripts de gestion de droits

-- cr_grant.sql

CREATE ROLE AN_CONS;
CREATE ROLE AN_ADMIN;

GRANT SELECT ON TEL TO AN_ADMIN; 
GRANT UPDATE ON TEL TO AN_ADMIN; 
GRANT DELETE ON TEL TO AN_ADMIN; 
GRANT INSERT ON TEL TO AN_ADMIN; 

GRANT SELECT ON TEL TO AN_UTIL; 
GRANT UPDATE ON TEL TO AN_UTIL; 

GRANT SELECT ON TEL TO AN_CONS; 
GRANT SELECT ON ANNUAIRE TO AN_CONS; 

GRANT AN_UTIL TO UTIL1;
GRANT AN_CONS TO UTIL2;

Un cahier des contraintes techniques

Un cahier des contraintes techniques (matérielles et logicielles) est nécessaire, surtout dans le cas de mise en place de progiciel.
Il sera transmis aux fournisseurs dès l'expression du besoin.

OS client (+ SP, + niveau kernel), type de navigateur, niveau d'HTML supporté, capacité mémoire et disque
OS serveur (+ SP, + niveau kernel)
logiciels systèmes (SGBDs
protocole supportés : TCP/IP, SQL*Net, webdav, samba, http, SSL, ...
et les caractéristiques techniques détailléesdes différents composant matériels du SI.

Un peu de méthode

Outre les méthodes classiques et les ateliers de génie logiciel associés (MERISE, MEGA, CASEs, UML) qui dépendent de la technologie retenue et des choix stratégiques de l'entreprise, on pourra mettre à profit une méthode comme XP, pratique et facile à mettre en oeuvre.

extrême programming : XP.
Comme son nom l'indique elle est très orienté développement mais l'assurance qualité est très présente dans cette méthode.
Les concepts sont simples et issues de l'expérience de la communauté des programmeurs. Il n'y a pas d'outil lourds à mettre en place , mais des préconisations de pratiques référenbtes (best practices).
En collaboration étroite et récurrente avec l'utilisateur final, la satisfaction de ce dernier est plus probable.

exemple : le manuel utilisateur peut servir, trèe en amont, de spécification détaillée.

Voir 'a gentle introduction to XP'

La phase de préproduction

la distribution du programme et/ou de son environnement

client lourd : fonctionnellement et ergonomiquement riche mais
pb de ressource du poste, pb de distribution sur tous les postes, pb de maintenance évolutive
client léger : poste 'léger', peu couteux, pas de distribution, mais ergonomie et fonctionnalité parfois limitée notamment a cause d'HTML .
exemple: client Notes lourd contre webmail (solution Web 2.O / Ajax ?)

autres exemples lourds : appli designer, applet, programme VB ou access. Leger : appli ASP/PHP, appli J2EE

la migration des données

pb de récupération de données
- compatibilité de type,
- pb d'extraction / export de logiciel anciens (données intégrées aux traitement)
- incohérence mise en évidence par les 'requéteurs' == fiabilisation des données
- optimisation du MD (normalisation / dénormalisation)
scripts ex nihilo (lourd mais propre) ou export / import (facile mais parasitée)

la migration évoquée ici concerne le passage de la BD de developpement vers la BD de test. Ce processus peut aussi être utilisé lors du développement en cas de récupération de données d'un ancien logiciel existant déja dans l'entreprise.

les procédures de mise en préproduction

jeux de données de test,
tests des scripts d'init, tests du pg,
montée en charge
- montée en volume (pb de stockage mais aussi de performance d'accès a otimiser éventuellement : pose d'accélérateur)
- montée des users (pb de charge réseau, système) et pb de concurrence d'accès / verrouillage
(outil de stress : http://www.opensta.org/ ,
pour apache : http://httpd.apache.org/test/ ou
le web application stress (WAS) tool de microsoft : http://support.microsoft.com/?kbid=324094
restriction des droits
intégration à un existant proche de la cible

la préproduction est partculièrement délicate lorsque l'environnement est éloigné de l'environnement de PROD. Il peut être nécessaire dans ce cas de faire les TESTs en PROD.
exemples : de easyPHP local Apache/Mysql@free.fr, de MYSQL à Oracle

Le cas des progiciels

Dans le cas d'un progiciel, la phase de développement est évidemment inexistante.
Importance :

des tests du progiciel dans l'environnement existant de l'entreprise
de son intégration dans l'environnement de production

Il doit idéalement vérifier le cahier des contraintes techniques (mais ca n'arrive jamais ;-(
... et dans le cas contraire subir des adaptations pour son intégration.

Adaptation des programmes système (coté client ou serveur)
- binaire compatible
- recompilation vers l'OS cible
- émulation
Adaptation base de données
- intégration d'une instance de base de données 'boite noire'
- transformation d'une BD 'boite noire' en schéma
- adaptation d'un schéma

La phase de production

dimensionnement des espaces de stockages et des serveurs
création des users finaux
sécurisation : politique d'artchivage, disponibilité, sauvegarde et restauration, DMZ, réplication / duplication
intégration avec le SI réel (modifications des liens vers les données ou ressources externes à l'appli)
mise en place des batchs
mise en place d'outils de contrôle en temps réel, de trace, d'indicateurs

le cas échéant, avant la mise en production effective de l'application, on formera les utilisateurs à l'utilisation du logiciel

La phase de maintenance

c'est la qu'on va tester la qualité du code, sa lisibilité, sa pérennité / portabilité
et ... la qualité de la doc

évolution fonctionnelle
correction des bugs éventuels
intégration à de nouveaux environnements matériels et logiciels
suivi / gestion des incidents : outils de Hot line ou outils de supervision (reseau,systeme, BDs : Netview, Patrol, agents SNMP, Nagios,...)
suivi des indicateurs

Le système des informations et la gouvernance informatique

Le système d'informations (S.I) de l'entreprise est un objet complexe

Complexité de l'informatique, en terme :

d'infrastructures (matérielles et logicielles
d'applications
de méthodes
de stratégie (héritée de la stratégie de l'entreprise ou de l'organisation)

On vise un meilleur controle des processus et une informatique orientée service.
La gouvernance informatique (IT governance) directement issue de la gouvernance d'entreprise, prend en compte l'organisation de manière systémique pour satisfaire ces objectifs d'efficacité.

exemples d'outils et référentiels associés à la gouvernance

(d'après le journal du net) Le mécanisme de la gouvernance s'appuie sur trois grands axes :
- la stratégie qui définit les objectifs de la DSI à moyen et à long terme ;
- le pilotage qui a pour but d'atteindre les objectifs fixés et de contrôler le système d'information ;
- l'organisation qui structure l'activité informatique de l'entreprise au travers d'un cadre de référence.

ITIL : I.T Infrastructure Library (Bibliothèque d'infrastructure informatique)
C 'est un ensemble de recommandations mises au point par le bureau gouvernemental du commerce britanique (OGC)
Elles visent à améliorer la qualité des 'services' informatiques fournis aux utilisateurs.
Certains des septs processus abordés parles ouvrages de la librairie ITIL concernent le processus de mise en production.
Les grandes sociétés de service et de consulting anglo saxonnes s'appuient sur cette librairie. ITIL est conforme à la norme ISO 20000.

les principaux livres de la librairie ITIL (d'après Frédéric Georgel)

Pour plus d'infos voir le site officiel de l'ITIL

le COBIT, Control objectives for information and related technology,
Le modèle CobiT (Control Objectives for Business & Related Technology) est une méthode de Maîtrise des Systèmes d’Information (IT Gouvernance) et d'audit de systèmes d'information, éditée par l’Information System Audit & Control Association (ISACA) en 1996. C'est un modèle qui vise à aider le management à gérer les risques (sécurité, fiabilité, conformité) et les investissements.

Domaines et processus de COBIT (d'après Frédéric Georgel)