• le TP3 est la première ;
• le TP4 est la seconde ;
• le TP5 réalise l'objectif final

D'autant plus que je vais vous demander d'échanger vos codes.

Ex : NF16021 et NF16037 ne sont pas dans la même séance de TP.
Néanmoins à l'issue du TP3 voici ce qui se passera :

Ils devront s'envoyer par mail leurs sources
et faire le TP4 à partir des sources développés par l'autre groupe.

Il se passera la même chose pour le TP4 : vous hériterez d'une double histoire
de développement (good luck).

Les échanges seront aléatoirements générés.
 
 

Conseils :
 

1. élaborez des solutions simples et robustes
2. commentez intelligemment vos codes sources
3. utilisez des noms de variables et de fonctions qui soient clairs et qui donnent de l'information utile
4. effectuez des tests incrémentaux sur les fonctions : ghost test first,  partial test second, final test at last
5. construisez un fichier de trace du développement.

C'est quoi un fichier de trace de développement ?

Simple !  Toute modification significative de votre code source,
test, changement de direction de développement, nouvelle idée
devront être obligatoirement commentés dans un fichier texte.
Préciser la date et l'heure de la modification.
C'est donc bien plus informant que les commentaires.
Si vous vous trompez n'hésitez pas à expliquer pourquoi
quelque chose n'a pas marché et comment vous avez résolu le problème.
C'est bien plus complet que les commentaires.

Exemple  de fichier, il s'appelle TP3.txt et il est lié au code tp3.c

voici ce que donnera un "cat TP3.txt" du compte NF16027

************* NF16027 tp3********************
le 161002 10h30
tests finaux de la fonction truc
tous les cas ont ete testes
elle repond aux specifications (voir 151002 12h30)

************** NF16027 tp3 *******************
le 151002  12h30
création de la fonction truc
elle comporte tels parametres de tels types.
Elle a ete cree pour telle raison et on definit aussi ses specifications.
Elle a ete teste en ghost, puis en fonctionnement avec tels cas,

etc.

Vous pouvez remarquer que les dates vont en décroissant.
Utilisez le fichier de trace comme une pile, donc empilez vos textes.
Soyez bref mais clair ! Toute phrase de plus de 3 lignes est à bannir.
Vous remarquerez que le fichier de trace comporte un numéro de compte
et un label de tp. C'est ce que vous voyez dans :

************** NF16027 tp3 *******************

Puisque vous échangerez les tps, il faut savoir qui a fait quoi.

ATTENTION :

Ce fichier sera aussi envoyé au groupe qui reprendra votre travail
et il en évaluera la pertinence.
Ils corrigeront aussi ce qu'ils penseront être des erreurs réelles (ou imaginaires ...)
et noterons la qualité du développement selon deux rubriques :

critères pour le code :

1. propre (indentations, identificateurs signifiants quelque chose, etc.)
2. facile à comprendre
3. facile à faire évoluer
4. commentaires pertinents.

1. consistant (c'est autre chose qu'un simple copier/coller des commentaires du source, plus informant, plus complet)
2. compréhensible (faire des phrases courtes)
3. fautes de frappe, orthographe (sauf accents puisque je ne veux que de l'ASCII sur [0,127] )
4. en adéquation avec le code source.

NF16023 note NF16047
note globale : 1.25

puis, pour les deux rubriques et pour chaque critère
ce que vous en pensez.
Dans cet exemple c'est le groupe NF16023 qui note le groupe NF16047.

Après avoir présenté le TP que vous aurez élaboré à l'aide
du code dont vous aurez hérité, vous enverrez ce fichier par mail
à votre chargé de TP, il restera confidentiel.

Nous aurons donc aussi les originaux des sources et des fichiers de trace,
ne l'oubliez pas.

Nous vous noterons aussi le TP (75%) MAIS aussi la notation que les autres vous auront donné.
Une notation laxiste vous retirera des points sur le tp suivant, idem pour une notation
tros sévère.

Vous rendrez donc comme documents :

1. votre source du tp qui complète forcément la suite des autres sources (sauf pour le premier, le tp3)
2. votre fichier trace du tp (idem)
3. un fichier texte de la notation (sauf pour le premier, le tp3).

C'est quoi un ghost test ?

Le programmeur parfait n'existe pas ! (idem homme parfait, femme parfaite et patron parfait )

Alors appliquer ces règles :

1. écrire l'en-tête de la nouvelle fonction (type retrouné, types et identificateurs des paramètres)
2. mettre une {
3. faire afficher les paramètres
4. faire un "return" avec un exemple de valeur retournée
5. mettre une }
6. insérer un ou plusieurs appels de la nouvelle fonction où elle doit être appelée
7. compiler le code souce
8. (recommencer ) -> tester plusieurs fois l'appel de la fonction avec différentes valeurs de paramètres.

Cela fonctionne-t-il ? Recupérez-vous les bons paramètres en toutes circonstances
d'appel de cette fonction "ghost" ?

C'est quoi un partial test ?

Vous croyez pouvoir développer un code qui fonctionne du premier coup ?
Si oui changez de métier.
Si non lisez ceci :

répéter pour chaque nouvelle fonction

1. faire un (autre) petit bout de la fonction
2. tester à fond
3. cela fonctionne ?
4. oui aller en 1 en enlevant les parenthèses
5. non vérifier :
1. l'initialisation des variables, des variables de controle de boucle
2. les tests et conditions (dans les "if", "switch", "for", "do", "while", ...)
3. utiliser le deboggueur
4. si ras-le-bol alors goto zen;

zen :

Pensez à tirer un listing et étudier calmement le problème
Arrêtez d'en... votre binome (pour les personnes qui pensent toujours que les problèmes viennent des autres et jamais d'eux-mêmes, voir homme parfait et femme parfaite)
Arrêtez de dire que vous n'êtes pas bon, c'est pas vrai, vous allez le devenir ...
Sortez proprement de votre cession sans taper sur un objet ou autre ...
Allez vous détendre, vous y reviendrez plus tard à ce TP.
 
 

C'est quoi un final test (sur une fonction) ?

Elaborer tous les tests possibles et immaginables d'appel de la fonction :
 

• cas normaux d'usage
• cas limites
• cas en dehors des limites
• cas de fonctionnement en hyper-espace

SUITE