Cahier des Charges SofTeam composée de : Présente

Cahier des Charges
SofTeam
composée de :
Auriau Florian Bettan Mickaël
Kauffmann Albin Savoye Rémi
Présente
1
KronenBase - Cahier des charges
Projet Epita Promo 2009
Table des matières
Introduction
3
1 Présentation du groupe et du projet
1.1 Le Groupe . . . . . . . . . . . . . . .
1.1.1 Florian Auriau . . . . . . . .
1.1.2 Mickaël Bettan . . . . . . .
1.1.3 Albin Kauffmann . . . . . .
1.1.4 Rémi Savoye . . . . . . . . .
1.2 Le Projet . . . . . . . . . . . . . . .
1.2.1 Nature . . . . . . . . . . . . .
1.2.2 Choix . . . . . . . . . . . . .
1.2.3 Intérêts . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
3
3
4
4
4
4
4
2 Découpage du projet
2.1 Gestion des données et de la mémoire . . . .
2.2 Algorithmes . . . . . . . . . . . . . . . . . . .
2.3 Multitâches . . . . . . . . . . . . . . . . . . .
2.4 Gestion du mode réseau . . . . . . . . . . . .
2.5 Accès à la base avec un client Web . . . . . .
2.6 Développement d’une application : EpitaBase
2.6.1 Le programme serveur . . . . . . . . .
2.6.2 Le programme client . . . . . . . . . .
2.6.3 La correspondance entre les deux . . .
2.7 Site web . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
6
7
7
7
7
7
8
3 Distribution des tâches et Planning
3.1 Répartition des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Planning de réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
8
4 Moyens mis en œuvre
4.1 Nos conditions de travail
4.2 Le Serveur et CVS . . .
4.3 Outils matériels . . . . .
4.4 Solution logiciel . . . . .
4.5 Aspect économique . . .
Conclusion
TABLE DES MATIÈRES
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
10
11
11
2/11
KronenBase - Cahier des charges
Projet Epita Promo 2009
Introduction
Dans le cadre de notre deuxième année à l’EPITA, il nous est demandé de développer un
logiciel sur la plateforme de notre choix (UNIX, Windows, . . .). Nous avons opté pour KronenBase, une librairie de gestion de base de donnée en réseau codée en C/C++, utilisable pour de
nombreuses structures de données, sous UNIX. Afin de montrer son fonctionnement, nous développerons en parallèle l’application EpitaBase. Elle permettra à toute personne faisant partie de
l’école d’avoir accès à un certain nombre de renseignements comme les notes, les emploi du temps
des professeurs et des élèves. . . EpitaBase utilisera donc toutes les fonctionnalités de KronenBase
et sera disponible aussi bien localement que sur le web. Ce cahier des charges va expliquer en
détails les différents points de notre projet.
1
Présentation du groupe et du projet
1.1
Le Groupe
Notre groupe, SofTeam, est constitué de quatre spé hyper motivé !
Albin Kauffmann, le chef de projet, est en A2 ainsi que Florian Auriau, tandis que Mickaël
Bettan et Rémi Savoye sont en C1. Cependant, nous étions tous dans la même classe l’année
dernière, ce qui implique que nous nous connaissons bien. La constitution de notre équipe SofTeam
s’est effectué en même temps que le choix du sujet, ceci afin d’être certain que chaque membre
travaille sur ce qu’il aime et donc qu’il se passionne à fond . . .
Voici une présentation non exhaustive de nous quatre :
1.1.1
Florian Auriau
J’ai 18 ans, j’habite dans le 15ème arrondissement en tant qu’étudiant mais ma famille est en
Normandie. L’an passé, je faisais parti du groupe de projet Plein Gaz. J’ai appris énormément de
choses grâce à ce projet et j’espère bien qu’il en sera de même cette année. Je vais principalement
m’occuper d’écrire les différents algorithmes de recherche, tri, ajout. . .
1.1.2
Mickaël Bettan
J’ai 19 ans. J’habite chez mes parents à Vanves. L’an dernier, je faisais partit du projet
SelFiShRaCeR. Je suis en spé C1. L’an dernier, le projet m’as beaucoup apporté dans mon
apprentissage informatique, le travail en équipe m’as montré qu’un projet informatique ne peut
pas se concevoir seul. Le travail en équipe est la clé de la réussite. De plus, lors de ces dernières
vacances scolaires, j’ai fait un logiciel de gestion de stock d’un magasin de chaussures. Pour créer
mon logiciel, j’ai utilisé une base de donnée (paradox) intégré dans delphi afin de pouvoir gérer
le stock de manière facile et efficace. Je ne connaissais pas du tout ce sytème de base de donnée
et cela m’a vraiment passionné. J’espère que ce projet va beaucoup m’apporter.
1.1.3
Albin Kauffmann
Ayant 19 ans, voici maintenant un an que je suis au Kremlin Bicêtre dans un studio de
17,74 m2 . Ceci explique le fait qu’il m’est très agréable de rentrer sur ma ville natale, à savoir
Nancy, là où j’ai notamment passé mes grandes vacances. Durant ces vacances, j’ai effectué
un stage dans un services de communications sur IP à France Telecom. J’ai ainsi découvert
l’importance des techniques de communication au sein de l’entreprise et cela m’a donc amené
vers la bonne idée de réécrire par nous même un système de gestion de base de données (SGBD).
1 PRÉSENTATION DU GROUPE ET DU PROJET
3/11
KronenBase - Cahier des charges
Projet Epita Promo 2009
La réalisation de ce projet concret nous amenera donc à découvrir des choses très intéressantes
sur des sytèmes que nous utilisons tous les jours sans vraiment le savoir.
1.1.4
Rémi Savoye
Originaire du Pas de Calais, j’ai intégré l’EPITA l’année dernière. J’ai toujours aimé l’informatique, et j’adore toucher à tout, autant la programmation que le graphisme, en passant par
le réseau. Que dire de plus, si ce n’est que j’adore EPITA, et plus particulièrement les projets
de prépa, parce qu’ils nous apprennent à travailler en équipe, et à apprendre les choses par nous
même. Durant les dernières vacances, j’ai fait un stage dans une entreprise de transports routiers,
et j’ai remarqué que les bases de données y étaient omniprésentes, d’où l’idée d’en refaire une
pour le projet.
1.2
1.2.1
Le Projet
Nature
KronenBase sera une librairie que les développeurs pourront obtenir sous forme de fichiers
sources, permettant ainsi une bien meilleur portabilité du projet entre les diférentes plate-formes
UNIX. Ces fichiers sources permetteront la compilation de deux ".so" (Shared Object), l’un étant
destiné aux fonctions de serveur et l’autre aux fonctions de client. Le développeurs devra en fait
inclure dans ses sources un fichier en-tête ".h" pour pouvoir utiliser toutes les fonctions du ".so"
concerné. Parmi ces fonctions, il trouvera tout ce qui est nécessaire pour pouvoir gérer sa base de
données et les échanges réseau entre les clients et le serveur. Il lui restera donc comme travail :
– la mise au point de la structure de la base de données ainsi que de la façon dont les
recherches se feront (permettant ainsi un personnalisation très poussée).
– le développement des contrôles d’accès des clients (accès par mot de passe, restriction des
droits pour certains utilisateurs ...)
– le développement d’une interface graphique permettant à un client d’accéder facilement
aux données de la base.
– ...
Au travers d’EpitaBase, c’est donc ce que notre groupe réalisera, le but de ceci étant de montrer
clairement les possibilité qu’offre KronenBase.
1.2.2
Choix
Etant donné que nous devons, sauf cas exeptionnels, réaliser non pas un jeu comme l’an passé
mais un logiciel, nous nous sommes tout de suite orienté vers ce type de projet. Le développement
d’un gestionnaire de base de donnée en réseau nous a tous plu. Ainsi, nous nous sommes lancés
dans cette aventure. Nous avons également choisi de développer ce projet sous UNIX et en langage
C/C++.
1.2.3
Intérêts
Notre projet a un réel intérêt pour les utilisateurs qui pourront adapter la gestion de base de
données à un problème particulier, ou, dans le cadre précis de notre application EpitaBase, avoir
accès à bon nombre d’informations. Ce projet a aussi de nombreux intérêts pour nous. Outre
le fait qu’il nous permettra une nouvelle fois d’acquérir une expérience informatique en équipe,
il nous fera découvrir UNIX et le langage C/C++ dont nous aurons une grande utilité l’année
prochaine.
1 PRÉSENTATION DU GROUPE ET DU PROJET
4/11
KronenBase - Cahier des charges
2
Projet Epita Promo 2009
Découpage du projet
2.1
Gestion des données et de la mémoire
Pour la réalisation de ce projet, nous allons utiliser deux types de mémoires :
– la mémoire vive à accès très rapide mais de taille limitée
– le disque dur à accès bien plus lent mais d’une taille bien plus importante (casi illimitée)
De plus, il faut ajouter que lors d’un plantage du serveur ou d’une coupure de courant, seul
les données stockées sur le disque dur sont "sauvées". Il faudra donc que les données présentes en
mémoire vive soit simplement une copie de données du disque dur. Ainsi, lorsqu’une modification
de la base sera faite, elle sera automatiquement transcrite sur le disque dur pour éviter toute
perte éventuelle.
En ce qui concerne le choix de charger des données dans la RAM, l’enjeux va être de taille.
En effet, il faudra trouver un bon compromis pour que les données auxquelles les utilisateurs
accèdent souvent soient dans cette mémoire vive et que les autres accès se fassent directement
sur le disque.
Quant aux données qui seront enregistrées sur le disque, elles se présenteront (très) grossièrement sous forme de tableaux à deux dimensions (à la manière d’une base de données relationnelles). Cependant, KronenBase permettera au développeur de personnaliser au maximum la
façon dont les algorithmes de recherche vont tourner (et donc d’optimiser ces recherches). Ceci
implique qu’il pourra :
– Demander des recherches d’attributs sur des structures arborescentes (ABR, AVL ou encore
arbres 2,3,4)
– Spécifier une fonction de hachage pour un attribut
– Demander une recherche dichotomique ou une recherche par interpolation linéaire
– ... (Je pense qu’on a encore beaucoup à apprendre)
Je m’explique un peu : En fait, le serveur pourra par exemple créer sur un attribut donné un
ABR de pointeurs vers le nième bit du fichier de données de la base. Ces pointeurs prennent certes
un peu de place à sauvegarder sur le disque dur mais permettent de limiter considérablement les
accès disques lors d’une recherche.
Cette personnalisation de la base (et tout d’abord sa structure) sera enregistrée dans un
fichier de configuration nommé « structure ». Il s’agit en fait d’un fichier texte interprété par
KronenBase. Le développeur devra donc créer lui même ce fichier à l’aide d’une syntaxe bien
particulière à notre projet. Ainsi, c’est ce fichier que KronenBase chargera en premier lors de son
démarrage. Pour être plus exact, l’ordinateur fera une copie de ce fichier dans le répertoire de la
base de données et pourra ainsi comparer l’ancien « .structure » avec le nouveau. En conséquence,
lors du redémarrage de KronenBase (ou de sa réinitialisation), le serveur pourra comparer les
éventuelles modifications que l’administrateur aurait pu faire et la mise à jour des fichiers de la
base de données sera automatique. Par exemple, si l’administrateur de la base rajoute un AVL
sur un attribut, cette AVL va automatiquement se créer lors de la réinitialisation de la base.
En conclusion, l’avantage de cette configuration « très » manuelle est de pouvoir faire tourner
le serveur dans un environnement UNIX sans interface graphique.
2.2
Algorithmes
Afin de gérer la base de données, il est important d’avoir à sa disposition des algorithmes de
tri, de recherche, d’ajout ou de suppression d’un élément. De plus nous comptons adapter notre
gestion de base de données en fonction du type de donnée qu’il traitera. Il faudra pouvoir utiliser
aussi bien des arbres de recherche, des arbres généraux, des tableaux de hachage, des listes. . .
2 DÉCOUPAGE DU PROJET
5/11
KronenBase - Cahier des charges
Projet Epita Promo 2009
Contrairement aux algorithmes que nous avons vu l’année dernière et que nous reverrons cette
année en cours, nos algorithmes devront impérativement gérer les redondances, et ainsi nos
fonctions pourront retourner une ou plusieurs valeur. Par exemple si l’on recherche dans la base
de données tous les élèves étant nés en janvier, nous pourrons retourner une liste complète de
ces élèves. Cette partie algorithmique sera donc assez conséquente.
2.3
Multitâches
Kronenbase devra être capable de gérer le multi-tâches et d’accomplir beaucoup plus de tâches
en parallèles. En effet, les differentes fonctions qui seront utilisées dans la base de données prendront un certain temps à s’accomplir, et certaines actions sur la bases nécessiteront l’exécution de
plusieurs de ces fonctions indépendamment les unes des autres. C’est pour cela que l’utilisation
du multitâches va nous permettre de faire de KronenBase une base de donnée rapide et efficace.
De plus, le fait de faire plusieurs tâches simultanément devra en aucun cas entrainer plusieurs
sources d’erreurs, comme une collision de donnée si deux clients essaient de modifier la même
donnée simultanément.
Le multithreading est le fait d’exécuter des tâches simultanément (multitâche). Les termes
multitâche et multithread ne sont pas totalement similaires. Le terme multithread indique une
application qui effectue différentes taches simultanément. Le terme de multitâche est un terme
plus général et plus commun pour parler d’un système capable de gérer plusieurs applications
simultanément.
Par mesure d’efficacité, nous utiliserons seulement le multithreading sur le serveur, le client
n’en ayant pas besoin.
De nombreux systèmes d’exploitation permettent aujourd’hui la programmation par threads.
Mais un problème de portabilité va se poser dès lors que les systèmes d’exploitations ne respectent
pas la norme POSIX. Dans le cas de Solaris, la bibliothèque de threads disponible est conforme
à la norme POSIX 1003.1c ce qui assure une certaine portabilité de l’applicatif en cas de portage
vers un autre système. Dans le cas des systèmes Microsoft, la bibliothèque utilisée est bien entendu
non conforme à cette norme POSIX.
Il existe aujourd’hui diverses bibliothèques permettant de manipuler des threads sous LINUX.
On dénombre deux principaux types d’implémentations de threads :
– Au niveau utilisateur (user-level). A ce moment la, la gestion des threads est entièrement
faite dans l’espace utilisateur.
– Au niveau noyau (kernel-level). Dans ce cas, les threads sont directement gérés par le noyau.
Nous essaierons d’utiliser des librairies à la norme POSIX sous linux.
2.4
Gestion du mode réseau
Le réseau dans KronenBase est d’une grande importance. En effet, de nombreux clients devront se connecter au serveur sous UNIX ou la base est gérée, pour demander des requêtes et
des modifications.
Pour cela, nous utiliserons des sockets. Nous devrons être en mesure de faire fonctionner
ces sockets aussi bien sous windows, que sous UNIX permettant une communication entre les
différents systèmes d’exploitations.
De plus, le fait que le client lise et écrive la base de donnée en réseau ne devra pas faire
ralentir la base de donnée.
En outre, nous avons décidé que la base de donnée pourrait être consultable par Internet à
travers d’un plugin PHP permettant de se connecter au socket UNIX et lire les données au fur
et à mesure.
2 DÉCOUPAGE DU PROJET
6/11
KronenBase - Cahier des charges
Projet Epita Promo 2009
Le mode de transfert TCP / UDP n’a pas encore été choisit mais de nombreux tests seront
effectués nous permettant de savoir lequel serait le plus rapide et adapté.
2.5
Accès à la base avec un client Web
Lorsque les utilisateurs d’une base de données sont en déplacement, il peut être très intéressant
pour eux d’y accéder à partir d’un simple client Web. Ainsi, avec KronenBase, le développeur
aura la possibilité d’inclure dans du code PHP des fontions d’accès à la base de données. Ces
accès se limiteront essentiellement à de la lecture pour des raisons de sécurité et de manque de
temps nécessaire à son développement (surtout qu’une fois la lecture implémenté, le reste ne sera
pas forcément très intéressant à développer).
Cette parti du projet est loin d’être la plus essentielle au fonctionnement d’EpitaBase. Cependant, elle nous permettra de se pencher plus en détail sur la « convergence des techniques
d’informations ». Quant à son développement, nous n’avons qu’une petite idée de la façon dont
elle fonctionnera : il faudra en fait installer sur le serveur KronenBase un serveur Apache et
ajouter des fonctionnalités au PHP. . . L’accès au site Web de la base se fera donc à l’aide de son
adresse IP ou d’un nom de domaine pointant vers cette adresse.
2.6
Développement d’une application : EpitaBase
Il s’agit d’une application se servant de la base de données Kronenbase. Dans un premier
temps, elle contiendra une liste d’élèves, celle de l’EPITA par exemple, et les classes de chacun.
Elle sera composée de deux parties : un programme serveur sous UNIX, sans interface, et des
programmes clients avec interface graphique.
2.6.1
Le programme serveur
Il tournera en continu sur un serveur UNIX. Il s’agira en fait d’une application faite à partir
de Kronenbase, à laquelle viendra s’ajouter un système d’utilisateurs expliqué un peu plus loin.
2.6.2
Le programme client
Ce programme servira à lire, modifier, ajouter, supprimer des données dans la base de données
du serveur à travers une interface graphique sous Linux.
Le choix de la librairie graphique oscille entre QT et wxWidget, qui sont des librairies graphiques gratuites et simples à utiliser. De plus, elles permettent de compiler une application sous
différentes plateformes, ce qui pourait être pratique si nous décidions de rendre l’aplication multi
plateformes.
De plus, l’application sera développée en français et en anglais, pour satisfaire un plus grand
nombre d’utilisateurs potentiels.
2.6.3
La correspondance entre les deux
Elle se fera par l’intermédiaire de requêtes, de la même manière que le php communique avec
les bases MySQL.
De plus, il ne faut pas que tout le monde puisse lire ou modifier la base. Epitabase comprendra
donc un système d’utilisateurs, différenciés par des login/mot de passe. Ces derniers se trouveront
sur le serveur, et seront cryptés, afin de dérouter les esprits malveillants.
2 DÉCOUPAGE DU PROJET
7/11
KronenBase - Cahier des charges
2.7
Projet Epita Promo 2009
Site web
Le site web se composera :
– d’une page d’accueil, avec un système de news afin de tenir informés les visiteurs,
– d’une présentation de nous quatre pour que les visiteurs nous connaissent,
– d’une page de contact pour les éventuels conseils, remarques ou critiques,
– de liens vers les sites qui nous ont apporté une aide quelconque pour l’avancement du
projet,
– d’une page de téléchargements où le projet, ses sources, et les soutenances pourront être
téléchargées,
– d’une page de projet, où les visiteurs pourront voir en détail l’avancement du projet, les
étapes en cours de réalisation, et des captures d’écran d’Epitabase.
L’hébergement est abordé dans la partie budget.
3
Distribution des tâches et Planning
3.1
Répartition des tâches
La répartition des tâches est un point important pour pouvoir travailler en équipe. En effet,
elle permet à chaque membre de s’orienter dans ses recherches et dans son travail. Pour notre
projet, les deux plus grosses tâches sont la gestion des données et les algorithmes de recherche :
ainsi, chaque membre du groupe participera à au moins une de ces deux grandes parties. Bien
sûr, cette répartition des tâches n’exclue pas un travail en groupe. Au contraire, nous devrons
beaucoup discuter ensemble pour mettre au point les différents point importants (types de donnée, prototypes de fonctions. . .). Voici donc cette répartition : ⊗ correspond à la tâche primaire
d’un membre, tandis que × correspond à une tâche secondaire.
Florian Auriau
Gestion des données
Michaël Bettan
Albin Kauffmann
Rémi Savoye
×
⊗
×
×
Algorithmes de recherche
⊗
×
Multitâches
×
⊗
⊗
Réseau
EpitaBase
×
3.2
⊗
⊗
Accès Web
Site Web
×
×
×
⊗
Planning de réalisation
Le planning de réalisation permet d’avoir une idée de l’enchaînement des différentes tâches
mais aussi de leur ampleurs. Comme nous l’avons déjà dit, la Gestion des données et les algorithmes de recherche prendront le plus de temps. Il faudra en parallèle, développer le réseau et
le multitâches. . . et bien évidemment EpitaBase.
3 DISTRIBUTION DES TÂCHES ET PLANNING
8/11
KronenBase - Cahier des charges
1ère soutenance
Nov
Déc
Projet Epita Promo 2009
2éme soutenance
Janv
Févr
3éme soutenance
Mars
Avril
Dernière soutenance
Mai
Juin
Gestion des données
Algorithmes de recherche
Rédac
Multitâches
cahier
Débogage
des
et
charges
finitions
Réseau
EpitaBase
Accès Web
Site Web
4
4.1
Moyens mis en œuvre
Nos conditions de travail
Afin de mener à bien ce projet, il est certain qu’il va falloir mettre au point une organisation
nous permettant à certain moments de travailler ensemble et à d’autres, de travailler individuellement. Travailler en équipe permet de mettre au point un certain nombre de choses comme la
façon dont fonctionnent les algorithmes très importants, les prototypes de fonctions, les types de
données . . . Lors de ce travail en équipe, nous nous retrouverons la plupart du temps dans les
locaux de l’EPITA afin de pouvoir disposer de salles de classe avec un tableau (très pratique pour
discuter « algorithme ») et d’un réseau informatique très important. Par ailleurs, il est fortement
possible que ces temps de travail se déroulent au Kremlin-Bicêtre, les locaux étant plus prêts
de chacun de nous. Quant au travail individuel, il a le mérite d’être plus productif (lorsque par
exemple, on devra écrire des algorithmes dont on connait déjà les spécifications . . .). De plus,
celui-ci seront facilité par la présence d’un serveur CVS.
4.2
Le Serveur et CVS
Le projet KronenBase necessitant un serveur UNIX pour tester le projet, nous avons décider
de mettre en place notre propre serveur UNIX. Un des membres a mis en place un de ses
ordinateurs sous une debian, afin d’effectuer tous les tests de serveurs UNIX. Ce serveur, placé
sur internet par un port ssh et ftp, va nous permettre d’effectuer tous les tests que nous aurons
besoin de faire. Ce serveur sera en ligne 24h/24 et 7j/7 pour pouvoir effectuer des tests et des
mises à jour à n’importe quel heure de la nuit ou du jour.
De plus, l’un des gros inconvénient que chacun des membres du groupe a rencontré l’an dernier
dans le projet de sup, était la mise en commun des sources du projet. Nous avons décidé ainsi
d’utiliser un utilitaire reconnu et utilisé dans le monde des developpeurs, CVS, afin de pouvoir
mettre à jour facilement les sources du projet. CVS (Concurrent Versions System) est un outil
d’aide au développement de logiciels. CVS permet une gestion efficace et riche des différentes
versions pour un projet logiciel. Cela passe notamment par la mise en place d’un suivi, et par
conséquent d’un historique, pour l’ensemble des fichiers appartenant au projet. L’un des autres
points forts de CVS est de permettre et de favoriser un développement en équipe. En effet, il
permet un stockage centralisé du code source sur un serveur et gère les accès concurrents sur les
fichiers de développement. Ainsi, nous avons mis en place un serveur CVS sur la machine en ligne
de l’équipe SoftTeam. Chacun des membres pourra alors se connecter pour modifier les differents
fichiers sources du projet.
4 MOYENS MIS EN ŒUVRE
9/11
KronenBase - Cahier des charges
4.3
Projet Epita Promo 2009
Outils matériels
L’équipe SoftTeam possède déjà une très bonne configuration matérielle lui permettant de
travailler en toute tranquilité.
Voici un tableau montrant les caractéristiques des ordinateurs de chacun :
Florian Auriau
Michaël Bettan
Albin Kauffmann
Rémi Savoye
AMD XP 2400+
512 DDR
Ati 9600 Pro
175 Go
CRT 17 pouces
AMD XP 3200+
2×512DDR dual channel
Leadtek Gforce 4 Ti 4400
200 Go
LCD 17 pouces
HP PSC 1215
centrino 1,7 Ghz
512 DDR
ATI Mobility 9700
60 Go
portable (1400*1050)
HP LaserJet 4L (Nancy)
AMD 64 3000+
2×512DDR dual channel
gigabyte gforce 6600 GT
360 Go
LCD 17 pouces
HP PSC 1310
Nos imprimantes étant toutes fonctionnelles et de qualité, il sera aiser d’imprimer nos rapports
de soutenances en temps et en heure.
D’autre part, l’hébergement du site web était un problème conséquent. Il nous fallait trouver
un nom de domaine facilement utilisable et étant hébergé sur un vrai hébergeur permettant à
des milliers d’utilisateurs de se connecter simultanément. Nous avons trouvé un service gratuit
1and1.fr permettant de créer un domaine en .info gratuitement et un hébergement complet
gratuit pendant 3 ans. Nous avons ainsi choisit www.kronenbase.info et avons configuré tous les
services de l’hébergement. Cet hébergeur étant totalement gratuit et proposant l’ensemble des
services que nous avions besoin, nous avons économisé de nombreuses dépenses.
De plus, nous devons faire honneur au nom de notre projet et sponsoriser les bières Kronenbourg
par quelques petits achats de bières chaque jour.
Le pack de 26×25 cl - Kronenbourg : 9.95 e × 365,25 jours × 4 personnes = 14536.95 e
Le prix total de l’aspect matériel revient donc à 14536.95 e, ce qui est une somme très
raisonnable pour un tel projet.
4.4
Solution logiciel
Deux types de logiciels vont être nécessaires : les systèmes d’exploitation et les logiciels. Pour
le système d’exploitation, nous possédions tous un système Microsoft Windows XP Professionnel
mais nous ne possédons pas de système UNIX/Linux.
KronenBase ayant un serveur fonctionnant sous UNIX/Linux, une distribution Linux est
nécessaire pour chacun.
Nos moyens étant limités, nous nous sommes tournés vers des distributions Linux, libre et
gratuites : Debian et Gentoo.
A l’heure actuel, nous avons tous testé ces deux distributions apportants des atouts et des
inconvénients différents.
Nom
Emacs
Dev C++
EasyPHP
Adobe Photoshop CS2
Macromedia Flash 8
Macromedia Dreamweaver 8
Libre
X
X
X
Descriptif
Développer sous Linux
Développer sous Windows
Montrer notre beau site
Faire des beaux dessins
Souriez, attention au flash !
Faire un beau site
Prix
0.00 e
0.00 e
0.00 e
501.88 e
645.00 e
519.00 e
Le prix total que nous couterons ces différents logiciels est de 1665,88 e.
4 MOYENS MIS EN ŒUVRE
10/11
KronenBase - Cahier des charges
4.5
Projet Epita Promo 2009
Aspect économique
L’aspect financier de ce projet est un point assez important. En effet, si nous ne pouvons pas
payer tous les moyens matériels et logiciels que nous necessitons, alors ce projet ne pourra pas
atteindre ses objectifs. En effet, un ordinateur trop long avec des logiciels inadaptés donnera un
résultat très médiocre.
Heureusement, nous possédons déjà des ordinateurs surpuissants afin de pouvoir passer des
nuits longues et exitantes à développer ce projet. Mais un trou financier dans notre budjet annuel
se fera forcément ressentir étant donné l’ampleur des futures dépenses. Nous envisageons de faire
une demande auprès de Mme Cavatorta pour rembourser ces investissements que nous allons
mettre de notre poche.
Conclusion
Pour conclure, nous pouvons dire que la réalisation de ce projet sera pour nous tous l’occasion
d’acquérir de multiples connaissances sur le C, le C++ et UNIX. Nous aurons une nouvelle fois
à gérer notre temps et à travailler en équipe. Nous espérons réussir à relever les difficultés que
comporte ce projet afin de le mener à terme en cette fin d’année.
4 MOYENS MIS EN ŒUVRE
11/11