Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 3 sur 3
  1. #1
    Invité de passage
    Inscrit en
    janvier 2007
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 1
    Points : 0
    Points
    0

    Par défaut Evalutation SW - duree jour/homme

    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!

  2. #2
    Membre actif
    Profil pro Elverion
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2008
    Messages
    174
    Détails du profil
    Informations personnelles :
    Nom : Elverion

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2008
    Messages : 174
    Points : 174
    Points
    174

    Par défaut

    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
    Vous n'arrivez pas à faire ce que vous voulez avec Linux?
    Read The Fine Manual !==>The Linux Documentation Project

  3. #3
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 136
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 136
    Points : 9 140
    Points
    9 140

    Par défaut

    Citation Envoyé par Elverion Voir le message
    (.../...)
    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 :
    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 :
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •