1 Architecture applicative
Le système d'information décrit dans ce document est considéré comme une première
version assurant le premier niveau des besoins fonctionnels. Ce système est appelé à évoluer
pendant plusieurs années de différentes façons : par l'ajout de nouvelles fonctions mais aussi
par l'évolution de l'existant. Cela implique la mise en place d'une architecture applicative
adaptée à ces contraintes.
L'architecture applicative du système d'information sera structurée tant que possible en
éléments indépendants pouvant être testés séparément, dans le cadre d'une architecture
orientée services.
partie de la documentation
sous la forme d'un dictionnaire. Au cours de la phase de réalisation, il sera très certainement
nécessaire de développer des « bouchons » ou équivalents, qui seront également fournis et
décrits.
2 Solutions techniques attendues
Compte tenu de la particularité du périmètre fonctionnel, ce projet ne peut en principe
spécifiquement.
Sur le plan technique, la solution sera basée :
Sur une architecture logique n-tiers, déployable indifféremment sur un ou
;
Sur le système d'exploitation Linux;
Uniquement avec des composants open source ;
Sur le langage Java, avec les dernières versions stabilisées de JEE et du SDK ;
des frameworks suivants est recommandée pour assurer la reprise du
:
o : JSF 2/Richfaces 4.X
o Persistence des données : JPA implémenté par hibernate
o rsion de contrôle : Spring ou EJB 3
sera
fortement apprécié.
(Identification, autorisation) pourra
reposer sur une solution pré-existante ou une solution développée pour les
moyens du projet. Le soumissionnaire devra argumenter son choix sachant que la
solution doit être suffisamment modulaire pour permettre de brancher moyennant
quelques paramétrages et
type LDAP ou CAS.
La couche de service doit être indépendante des technologies utilisées pour
; cela afin d
sa charte sans remanier le code de la couche service (exemple : passer de
Richfaces/JSF2 à ExtJS)
pas de procédures internes relevant de la
gestion des fonctions métiers ;
Tous les échanges entre postes de travail et application seront effectués avec le
protocole sécurisé https.
La compilation, la structuration des répertoires et la gestion des dépendances du
projet devront reposer sur la solution MAVEN.
Le choix de la base de données s'est porté sur le SGBD libre PostgreSQL.
Le code source devra être couvert par des tests unitaires qui porteront sur des
st pas attendu que les tests unitaires
es
: JSFUnit, Warp) ou de
plateformes de tests (exemple : Arquillian) dédiés.
3 Outils de développement
3.1 Environnement de développement
nts des plugins
permettant une meilleure intégration des frameworks retenus, mais aussi de plugins
ent.
3.2 Gestionnaire de codes sources(SCM)
s sources subversion ou git. Son
choix devra être argumenté.
u
SCM contenant le code source du projet .
de sources du projet à
INRA sera à la charge du titulaire.
Remarque :
La documentation technique du projet pourra également être versionnée au sein du SCM
puis mise à disposition via le wiki de la forge logicielle (capable de pointer vers une ressource
3.3 Forge logicielle
titulaire une forge logicielle. Cette forge logicielle devra
communiquer en lecture avec le SCM retenu.
4 Performances
Les temps de réponse ci-desso
conditions normales.
La mesure des performances se fera dans le contexte suivant :
une connexion « haute performance » à 256ko/s
une connexion « de terrain » : la situation du poste de travail reste à définir,
une connexion « haute performance
page dépendra de la fonction sous-jacente concernée :
délai devra rester inférieur à la seconde ;
Quan :
devra rester inférieur à 8 secondes.
Ces temps de réponse doivent être garantis pour 50 utilisateurs simultanés . À cette
outils dédiés open source
teurs évolue positivement dans le temps, une « simple » évolution
des caractéristiques des serveurs doit permettre de conserver ces temps de réponse.
Dans sa proposition, le soumissionnaire précisera la configuration matérielle souhaitée
pour le ou les serveurs hébergeant l'application.
5 Continuité de service
onible sept jours sur sept ; en cas de problème majeur, une
té de
service.
Les opérations techniques (sauvegardes et autres) auront lieu quotidiennement en
période nocturne , même si une
légère dégradation des performances est acceptable pendant cette opération.
La sauvegarde de la base de données sera prise en charge dans le cadre standard des
opérations effectuées sur ce type de serveur.
6 Volumétrie
Cette valeur ne prend pas en compte les données nécessaires au fonctionnement
les variables « système ».
7 Contraintes logicielles sur les serveurs
voir utiliser
les éléments suivants, dans la version proposée ou dans une version ultérieure :
Item Énoncé
Linux (Distribution centos 6.X ou ubuntu server
12.04 LTS)
administrateur.
Journaux et fichiers
temporaires la purge des fichiers temporaires.
Protocoles Le seul protocole autorisé entre le poste client et le frontal Web est HTTPS.
SGBD PostgreSQL 9.1 ou ultérieure
Serveur HTTP Apache 2.2.3 (en frontal) avec redirection via
mod_jk ou mod_proxy
sont
1. Tomcat 7.X
conteneur JEE 6,
2. Glassfish dans le cas contraire.
JEE et JDK JEE 6 et JDK 1.6
Protocole WS REST
Annuaire
U dans sa dernière version
Contraintes logicielles
La nature exacte et la version de tous les éléments présents dans la proposition technique
seront précisées par le soumissionnaire.
8 Environnement technique, contexte et
application, base de données, espace de stockage tiers si utile) et physiques nécessaires au
8.1 Phase de développement
Le développement sera guidé par les priorités fonctionnelles et techniques qui auront été
titulaire.
Sans attendre la livraison définitive d un lot
1de développements un scénario
fonctionnalité aura été développé, le titulaire déploiera sur un
environnement de tests de pré-vérification
Chacune de ces versions intermédiaires ; et
part (tag) dans le SCM retenu. Ces numéros de versions
intermédiaires seront utilisés par les testeurs
forge logicielle.
Remarque :
La phase de pré-vérification est explicitée ICI.
8.2 Phase de VA2
Une première validation à vocation fonctionnelle sera effectuée sur la plateforme du
titulaire.
recette INRA. Lors de cette phase, cet environnement sera accessible au titulaire : chargement
Afin de gagner du temps dans le déploiement du SI au sein de
de le titulaire .
L
8.3 Phase de VSR3 et période de garantie
Le titulaire aura accès à un environnement de tests, identique en performances à
services spécifiques.
8.4 Phase de production
pouvant
être ponctuellement ouvert au titulaire selon le contexte.
Remarque :
Pendant les phases de VA, de VSR et de garantie, le titulaire pourra demander ponctuellement
-validation sur sa propre plateforme.
9 Postes clients et Navigateurs
Il est souhaité que les écrans affichés dans le navigateur prennent en compte
automatiquement la résolution du poste client. Si cela n'est pas le cas, la résolution par défaut
de 1280 x 800 sera choisie.
L'application devra fonctionner à 100 % de ses possibilités sur les navigateurs suivants :
Firefox 4 et supérieurs,
2
Vérification ou recette utilisateur : aptitude à répondre aux besoins exprimés
dans le cahier des charges.
3
Vérification en Service Régulier
utilisateurs, en conditions réelles.
Internet Explorer 8 et supérieurs,
Safari 3 et supérieurs
Chrome 12
du risq
Dans le document
Cahier des clauses techniques particulières du Système d'Information Agrosyst
(Page 149-156)