Discussion :

[79RPM]

Hello,

Je suis a la recherche de technique pour évaluer de manière précise la conception de parties logicielles (C++ et C) dans le domaine de l'embarqué.

L’évaluation doit pouvoir me donner le nombre de jour/homme nécessaire pour compléter les taches suivantes:

1) maintenance de code (résolution de bug sur un système embarque).
2) développement de nouvelle fonctionnalité sur le même système embarque.

Je suis sur le point de mettre en pratique Agile et j'ai besoin de pouvoir estimer précisément un tache lors d'un sprint.

Merci!

[Elverion]

Bonjour,

Estimer à toujours été un problème très complexe dont il est difficile de trouver des techniques précises et fiables.
Cela s'explique entre autres par le fait que chaque développeur est différent et ce que l'un fait en 1 jour, l'autre le fera en 2 heures.

Néanmoins, des recherches se sont intéressées à ce problème comme par exemple celles de M. BOEHM.

Bon courage !
Cordialement,
Elverion

[el_slapper]

(.../...)
Cela s'explique entre autres par le fait que chaque développeur est différent et ce que l'un fait en 1 jour, l'autre le fera en 2 heures.(.../...)

Pire encore : suivant le domaine, ça peut s'inverser. Si on me compare à un programmeur web, pour faire un site web, c'est moi qui met 8 heures. Pour faire une moulinette complexe avec un format de données exotiques, c'est LUI qui met 8 heures et moi 2.

évaluer de manière précise

, comme le dit Elverion, ça n'existe pas. Pour plein de raisons.

(1) Les gens diffèrent.
(2) Le problème n'est jamais complètement identifié au moment ou on chiffre.
(3) Le problème change souvent en cours de route.

Le point 3 est sans doute moins méchant dans l'embarqué : le hardware à programmer est moins susceptible de changer que l'humeur d'un chef sur un projet de gestion-web-jeu.

Mais tu ne peux pas éviter les points un et deux. COCOMO, déjà cité par Elverion(avec un autre lien), est un outil qui permet de comprendre comment les choses se passent en moyenne, mais un projet est rarement dans la moyenne.

Tu cites les deux choses suivantes :

1) maintenance de code (résolution de bug sur un système embarque).
2) développement de nouvelle fonctionnalité sur le même système embarque.

La maintenance est spécialement vicieuse à chiffrer, parceque la difficulté dépend essentiellement de l'existant, et de la connaissance qu'on a. Si on a un code illisible que personne ne connait, on peut mettre dix, cent fois plus de temps que si le code est impeccable. J'ai récemment affronté le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
    MOVE     0    TO   BOO-ZON.                              
    MOVE     D-OBJ     TO   I-TAB-SPL-CUM.                   
    GO TO    R20B-02-2.                                      
R20B-02-1.    ADD  1    TO   I-TAB-SPL-CUM.                  
R20B-02-2.    IF   I-TAB-SPL-CUM  >    F-OBJ                 
    GO TO    R20B-02-4.                                      
    IF       BOO-ZON   =    1                                
    GO TO    R20B-02-4.                                      
    IF  SPL-NUM-ZON (I-TAB-SPL-CUM)   =    X-REG-CMP         
    NEXT SENTENCE ELSE                                       
    GO TO    R20B-03-4.                                      
    MOVE     1    TO   BOO-ZON.                              
    ADD 1 TO I-X-CAL.                                        
    MOVE     X-SPL-MT (I-TAB-SPL-CUM) TO   X-X-CAL (I-X-CAL).
R20B-03-4.                                                   
    GO TO    R20B-02-1.                                      
R20B-02-4.                                                   
    IF  BOO-ZON   =    0                                     
    MOVE     8    TO   COD-E     PERFORM Z

C'est une infamie. Ce code fait juste une boucle sur le tableau SPL-NUM-ZON, entre les valeurs de D-OBJ et F-OBJ, cherche si il trouve l'occurence ou se trouve X-REG-CMP, et plante si il ne trouve pas. Un code propre se comprend en quelques secondes. Il m'a fallu plus d'une heure pour comprendre ce truc, et surtout être sur que je n'avais rien loupé.

Si je dois faire une maintenance là-dessus pour trouver le bug, je vais m'arracher les cheveux. Si le code est propre, alors la maintenance sera facile, rapide, et le risque de bug sera plus faible; par exemple, je peux faire une boucle propre du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
*On recherche le numéro de la zone ou se trouve le montant recherché
    SET TROUVE-NON TO TRUE
    PERFORM VARYING I-TAB-SPL-CUM FROM D-OBJ BY 1
       UNTIL I-TAB-SPL-CUM > F-OBJ OR TROUVE-OUI
       IF  SPL-NUM-ZON (I-TAB-SPL-CUM)   =    X-REG-CMP    
          SET TROUVE-OUI TO TRUE
          ADD  1 TO I-X-CAL                                  
          MOVE X-SPL-MT (I-TAB-SPL-CUM) TO   X-X-CAL (I-X-CAL)
       END-IF
    END-PERFORM
*si non trouvé, on plante
    IF TROUVE-NON
       MOVE     8    TO   COD-E
       PERFORM Z 
    END-IF
    .

Ca reste un peu dur. Il reste à mettre des noms de variable parlants, et on en arrive à un code à peu près maintenable. Tout ça pour dire qu'avoir une estimation précise du cout d'une maintenance sans savoir à quoi ressemble le code, c'est juste impossible.