Démarrage d’un projet

Publié le par
Répondre

Objectifs :
Un projet est confié à une équipe de développeur et démarre par la remise d’un cahier des charges.
Celui-ci précise un échéancier à respecter. Soit avec des remises partielles de projet (appelé également revue), sinon les prévoir afin de présenter au client l’évolution du projet.

Processus Unifié :
Dans le cycle de développement du Processus Unifié, le démarrage d’un projet correspond à la phase d’«Inception».

Celle­-ci permet de spécifier les besoins et aussi une sorte d’étude de faisabilité où on effectue les recherches nécessaires pour décider si on poursuit ou non le projet (si on a les compétences requises).

Les activités :
­- Identifier les besoins et l’environnement dans lequel le système existe.
­- Identifier et réceptionner les ressources de développement, logicielles, matérielles et opératives
– Organiser son espace de travail et fixer les première règles d’organisation d’équipe
­- Mettre en évidence les « risques » par des tests de mise en œuvre (prototype)
­- Compléter le cahier de charges (en accord avec le client)
­- Organiser des réunions d’équipe, certaines avec le client
­- Rédiger un planning prévisionnel et une répartition des tâches
­- Rédiger les tests de validation (unitaires et finaux)
­- Rédiger les premiers documents (dossier de développement, la configuration du logicielle et matérielle …)

Documents :
Certains choix faits dans cette itération sont déterminants car, dans un cycle itératif et incrémental, il est parfois compliquer de changer en cours de route (arborescence, noms de fichiers, etc …).
Il est donc très important de toujours réfléchir plusieurs fois plutôt que de tout faire rapidement et généralement des erreurs et oublis s’additionne.
Vous allez créer un document « vierge » pour le rapport de projet (Il servira au client et de points importants pourront resurgir pour des prochains projets).
Définissez les en-­têtes, pieds de page, table des matières et une première structure. Vous allez l’enrichir au
fur et à mesure. Rédigez continuellement des petites notes « texte » en fonction de vos activités dans le projet (si possible journalier avec généralement un fichier DONE, une TODO_LIST … avec toujours la date et l’heure).
Idem pour certains « dessins » (synoptique, brouillons … qu’il faudra garder tant que les fichiers ne sont pas fini à 100%).
Les tests de mise en Å“uvre vont vous permettre de rédiger une première ébauche du manuel d’installation.

jQuery : Menu déroulant (accordéon)

Publié le par
Répondre

Menu simple

1
2
3
4
5
<ul>
    <li>menu</li>
    <li>menu</li>
    <li>menu</li>
</ul>
1
2
li {cursor:pointer;}
.actif {color: red}
1
2
3
4
$('li').click( function(){
    $(this).siblings().removeClass('actif');
    $(this).addClass('actif');    
})

Menu un peu plus élaborer avec une pseudo-classe :

1
2
3
4
5
6
7
8
9
10
11
<ul id="navigation">
    <li>
        <a href=""><h1>Titi</h1></a>
    </li>    
    <li>
        <a href=""><h1>Toto</h1></a>
    </li>    
    <li>
        <a href=""><h1>Tata</h1></a>
    </li>
</ul>
1
2
3
4
5
.selected {  background-color: rgba(233, 147, 26,0.5); }
li {
    border:solid;
    border-color:silver;
}
1
2
3
4
5
$('#navigation li a').click( function(e){
    e.preventDefault();
    $(this).closest('li').siblings().find('h1').removeClass('selected');
    $(this).find('h1').addClass('selected');    
})

CSS : Selecteur : after

Publié le par
Répondre

Utilisation du sélecteur after :

1
2
<div class="field"></div>
<div class="field"></div>
1
2
3
4
.field:after{
  content:"*";
  color:red;
}

Utilisation du sélecteur avec différents types de champs :

1
2
3
4
5
<div class="req"><button>bouton</button></div>
<div class="req"></div>
<div class="req"></div>
<div class="req"></div>
<div class="req"><textarea></textarea></div>
1
2
3
4
.req:after{
    content: "*";
    color: red;
}

Norme de développement

Publié le par
Répondre

Présentation générale
• Une ligne, y compris pour les commentaires, ne doit pas excéder 80 colonnes.
• Une seule instruction par ligne.
• Une fonction ne doit pas excéder 25 lignes entre les accolades.
• Un fichier ne doit pas contenir plus de 5 fonctions.
• Seuls les inclusions de headers (système ou non), les définitions, les defines, les prototypes et les macros sont autorisés dans les fichiers headers.
• Toute inclusion de header doit etre justifiée.
• Les macros multilignes sont interdites.
• Les prototypes de fonctions et les macros doivent se trouver exclusivement dans des fichiers .h. Les seules macros tolérées dans les fichiers .c sont celles qui activent des fonctionnalités (ex : _BSD_SOURCE).

Les commentaires
• Les commentaires peuvent se trouver dans tous les fichiers source.
• Il ne doit pas y avoir de commentaires dans le corps des fonctions.

Indentation
• L’indentation est obligatoire, quand on ouvre une accolade on indente et inversement.

Nomination
• Les objets (variables, fonctions, macros, types, fichiers ou répertoires) doivent avoir les noms les plus explicites ou mnémoniques.
• Les abréviations sont tolérées dans la mesure où elles permettent de réduire significativement la taille du nom sans en perdre le sens. Les parties des noms composites seront séparées par ’_’.
• Tous les identifiants (fonctions, macros, types, variables etc.) doivent être en anglais.
• Les noms de variables, de fonctions, de fichiers et de répertoires doivent être composés exclusivement de minuscules, de chiffres et de ’_’.
• Seuls les noms de macros sont en majuscules.
• Un typedef sur s_my_struct doit s’appeler t_my_struct.
• Un nom de structure doit commencer par s_.
• Un nom de type doit commencer par t_.
• Un nom d’union doit commencer par u_.
• Un nom de globale doit commencer par g_.
• Toute utilisation de variable globale doit etre jusitifiée.

Déclarations / Affectations
• On sautera une ligne entre la déclaration de variable et les instructions. On met une variable par ligne. Il ne doit pas y avoir d’autres lignes vides dans les blocs. Si vous avez envie de séparer des parties d’un bloc, faites soit plusieurs blocs, soit une fonction.
• On alignera les déclarations avec des tab (sous Emacs M-i). Cela est valable aussi pour les prototypes de fonction.
• Il est interdit d’affecter et de déclarer une variable en même temps, excepté lorsque l’on manipule des variables statiques ou globales
• Abuser des static pour faire des globales est interdit. Toute variable statique doit etre justifiée.
• Le symbole de pointeur (*) porte toujours sur la variable (ou fonction), et jamais sur le type

Structures de contrôle
• Une structure de contrôle sera toujours suivie d’un retour à la ligne et des accolades (même pour un if … return …).

Paramètres
• La déclaration des paramètres se fera à la syntaxe ISO/ANSI C.
• Les virgules ne sont autorisées que dans ce contexte.
• Au maximum on doit trouver 4 paramètres dans une fonction. Pour passer plus d’information, faites une structure et passez un pointeur sur cette structure (et jamais la structure directement).

Espaces
• Un espace derrière la virgule.
• Pas d’espace entre le nom d’une fonction et la ’(’.
• Un espace entre un mot clé C (avec ou sans argument) et la ’(’ ou le ’ ;’ dans le cas d’un return.
• Pas d’espace après un opérateur unaire.
• Tous les opérateurs binaires et ternaires sont séparés des arguments par un espace de part et d’autre.
• Il faut indenter les caractères qui suivent un #if ou un #ifdef.
• Il faut indenter les macros imbriquées.
• Une ligne vide doit séparer les définitions de fonctions.

Makefile
• Les règles $(NAME), clean, fclean, re et all sont obligatoires.
• Le projet est considéré comme non fonctionnel si le makefile relink.
• Dans le cas d’un projet multi-binaires, en plus des règles précédentes, vous devez avoir une règle all compilant les deux binaires ainsi qu’une règle spécifique à chaque binaire compilé.
• Dans le cas d’un projet faisant appel à une bibliothèque de fonctions (par exemple une libmy), votre Makefile doit compiler automatiquement cette bibliothèque.
• L’utilisation de ’wildcard’ (*.c par exemple) est interdite.

En-tête d’un fichier source de type « Application » ou « Implémentation d’utilitaire »

Publié le par
Répondre

L’en-tête d’un fichier source de type APPLICATION ou IMPLEMENTATION D’UTILITAIRE comporte les rubriques suivantes, dont certaines rubriques peuvent être facultatives.

Type :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**************************************
*
* NOM : nom.c
* TYPE : APPLICATION ou UTILITAIRE
* SUJET : descr. sommaire de la fct. d'usage
*
* AUTEUR : nom de (des) l'auteur(s)
* VERSION : numéro de version
* CREATION : date de création
* DER. MODIF. : date de dernière modification
*
* ACCES SRC : chemin du code source
* ACCES OBJ : chemin du code obj pour UTILITAIRE
* ACCES EXEC : chemin de l'exec pour APPLICATION
* FABRICATION : cmde de compil.ou nom de Makefile
*
* LIMITES : limites d'utilisation
* CONTRAINTES : contraintes d'implémentation
*
**************************************/

Exemple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**************************************
*
* NOM : video.c
* TYPE : UTILITAIRE
* SUJET : Gestion video d'un camera
*
* AUTEUR : VIEUX Nicolas
* VERSION : 0.1
* CREATION : 10/10/10
* DER. MODIF. : 10/10/10
*
* ACCES SRC : /usr/local/src/video.c
* ACCES OBJ : /usr/local/obj/video.o
* FABRICATION : gcc -Wall video.c -o video_v_0_1
*
* LIMITES : aucune
* CONTRAINTES : video.h
*
**************************************/