Dans le cadre du cours PDG (projet de groupe), les élèves en troisième année de Bachelor de l’HEIG-VD, orientation ingénierie logiciel, sont amenés à réaliser un projet de groupe.
Il est premièrement demandé de proposer un sujet, puis, dès que l’enseignant l’a validé, de rédiger un cahier des charges. Ensuite, les étudiants sont amenés à mettre en place ce projet en mettant en oeuvre les méthodes de gestion de projets vues en cours.
Le but de ce projet étant bien entendu pédagogique, il est donné la possibilité aux étudiants de manipuler de nouvelles technologies
Lors des matchs de Handball en ligue régionale et interrégionale le recueil de données de match tel que les buts inscrits, les fautes commises, le temps des temps-morts, … se fait à l’aide de papier et de stylo. Une fois ces feuilles de matchs remplies, il faut les envoyer à la fédération qui va les traiter une à une. Ce système pose plusieurs problèmes, premièrement il arrive régulièrement que la personne qui s’occupe de la table fasse une erreur au moment de remplir la feuille, ce qui peut entrainer des statistiques incohérentes et éventuellement des amandes pour le club responsable. Ensuite, étant donné que les données doivent être envoyées par la Poste les détails de match ne sont pas disponibles avant plusieurs jours. Finalement, il arrive que la personne responsable d’entrer les données sur le système depuis les feuilles de match commette des erreurs lors de la saisie.
La solution proposée pour répondre au problème est de mettre à disposition des clubs de handball suisses un système qui permette de saisir tous les faits de matchs. Le système sera composé de deux terminaux distincts, d’une part une application mobile, d’autre part un client web accessible via un navigateur internet. Ce système sera développé uniquement pour le handball.
L’application mobile servira à prendre note de tous les faits durant un match de handball. Cette tâche sera réservée aux chronométreurs de chaque club. Elle servira également à l’arbitre qui pourra valider, avant le match, la liste de joueur inscrit. Afin d’utiliser cette application il faudra bénéficier d’un compte chronométreur unique pour chaque club qui permettra d’utiliser l’application.
Concernant l’application web elle aura deux utilités, une pour les responsables de la fédération de handball (nommé administrateur dans la suite du document) et l’autre qui est libre d’accès.
Les administrateurs auront la possibilité d’administrer toutes les entrées permettant d’utiliser le système tel que le nom des équipes, les données des matchs, les informations des joueurs, etc. Au même titre que l’application mobile, afin de pouvoir accéder à ces fonctionnalités, il est nécessaire de s’identifier sur le serveur à l’aide d’un compte administrateu.
La partie libre d’accès concerne principalement, les entraineurs et les joueurs. Elle permet de consulter des statistiques sur les équipes, les joueurs et les championnats. Ces statistiques sont basées sur les données saisies à l’aide de l’application mobile. Ces statistiques permettent par exemple aux entraineurs de pouvoir consulté les statistiques sur les équipes adverses ce qui va leur permettre de mettre en place une stratégie pour les prochains matchs.
The default directory structure of a generated Ruby on Rails application:
|-- app
| |-- assets
| | |-- images
| | |-- javascripts
| | `-- stylesheets
| |-- controllers
| |-- helpers
| |-- mailers
| |-- models
| `-- views
| `-- layouts
|-- config
| |-- environments
| |-- initializers
| `-- locales
|-- db
|-- doc
|-- lib
| |-- assets
| `-- tasks
|-- log
|-- public
|-- script
|-- test
| |-- fixtures
| |-- functional
| |-- integration
| |-- performance
| `-- unit
|-- tmp
| `-- cache
| `-- assets
`-- vendor
|-- assets
| |-- javascripts
| `-- stylesheets
`-- plugins
app
Holds all the code that's specific to this particular application.
app/assets
Contains subdirectories for images, stylesheets, and JavaScript files.
app/controllers
Holds controllers that should be named like weblogs_controller.rb for automated URL mapping. All controllers should descend from ApplicationController which itself descends from ActionController::Base.
app/models
Holds models that should be named like post.rb. Models descend from ActiveRecord::Base by default.
app/views
Holds the template files for the view that should be named like weblogs/index.html.erb for the WeblogsController#index action. All views use eRuby syntax by default.
app/views/layouts
Holds the template files for layouts to be used with views. This models the common header/footer method of wrapping views. In your views, define a layout using the <tt>layout :default</tt> and create a file named default.html.erb. Inside default.html.erb, call <% yield %> to render the view using this layout.
app/helpers
Holds view helpers that should be named like weblogs_helper.rb. These are generated for you automatically when using generators for controllers. Helpers can be used to wrap functionality for your views into methods.
config
Configuration files for the Rails environment, the routing map, the database, and other dependencies.
db
Contains the database schema in schema.rb. db/migrate contains all the sequence of Migrations for your schema.
doc
This directory is where your application documentation will be stored when generated using <tt>rake doc:app</tt>
lib
Application specific libraries. Basically, any kind of custom code that doesn't belong under controllers, models, or helpers. This directory is in the load path.
public
The directory available for the web server. Also contains the dispatchers and the default HTML files. This should be set as the DOCUMENT_ROOT of your web server.
script
Helper scripts for automation and generation.
test
Unit and functional tests along with fixtures. When using the rails generate command, template test files will be generated for you and placed in this directory.
vendor
External libraries that the application depends on. Also includes the plugins subdirectory. If the app has frozen rails, those gems also go here, under vendor/rails/. This directory is in the load path.