Le Plan du Logiciel

Prof. SAHNOUN Zaidi Laboratoire Informatique Répartie (LIRE) Université Mentouri de Constantine

Introduction

 Pour conduire avec succès le développement d’un logiciel, on doit: Comprendre le travail à effectuer Connaître les ressources nécessaires Connaître les taches à accomplir Connaître les jalons et les étapes à suivre Connaître l’effort (coût) à dépenser Connaître le planning à suivre

 Le planning du projet est la deuxième étape dans la phase de développement. Cette étape est constituée de deux taches:

Une tache de recherche

   Une tache de recherche qui consiste à définir la portée de l’élément Logiciel dans un système informatisé. On utilise les spécifications du système comme guide pour décrire chaque fonction majeure du logiciel. Une description fonctionnelle avec d’autres données permet de conduire la tache d’estimation.

Une tache d’estimation

  Cette tache permet de prédire le futur en acceptant un certain degré d’incertitude (qui est l’une des caractéristiques du planning). Celle ci consiste à étudier certaines techniques permettant une estimation du coût et des délais du logiciel.

L’estimation

 L’estimation des ressources, le coût et le délai pour le développement d’un logiciel demande   de l’expérience, l’accès à de bonnes informations historiques et  le courage de donner des mesures quantitatives lorsque il n’existe que des données qualitatives.

Risques

 L’estimation comporte des risques liés à:  la complexité du projet: c’est une mesure relative et qui est une évaluation subjective menée très tôt durant le processus du planning.  la taille du projet: l’interdépendance entre les différents éléments du logiciel augmente très rapidement en fonction de la taille du projet. La décomposition qui est l’une des approches importantes d’estimation devient difficile.

Risques

 Le dégrée de structuration du projet. La facilité avec laquelle les fonctions peuvent être comportementalismes et la nature hiérarchique des informations à manipuler ont un impact sur l’estimation.  disponibilité d’informations historiques. Lorsque des mesures sur les projets passés sont disponibles, l’estimation peut être conduite avec une certaine confidence, les délais peuvent être établis pour éviter les difficultés rencontrées dans le passé et le risque global peut être réduit. « Ceux qui ne se rappellent pas le passé sont condamnés à le répéter »

Risques

 Le risque est mesuré par le dégrée d’incertitude dans les estimations quantitatives des ressources, du code et du délai.

Les objectifs du planning:

 C’est de fournir un cadre qui permet au gestionnaire de faire des estimations raisonnables sur les ressources, les coûts et les délais.  Les estimations seront faites dans un intervalle limité de temps au début du projet et seront mises à jour au fur et à mesure que le projet progresse.

La portée du Logiciel

 

Dilemme dans la tache d’estimation:

l’estimation doit être quantitative alors que les informations ne sont pas disponibles.  Les fonctions et les performances allouées au logiciel doivent être évaluées pour établir la portée du projet de façon non ambiguë et compréhensible.  Aux niveaux gestion et technique la portée du logiciel doit être délimitée, c’est-à-dire:   Les données quantitatives doivent être indiquées explicitement (nombre d’utilisateurs simultanés, le temps de réponse maximum...) Les contraintes et les limitations doivent être notées (taille mémoire par exemple)

 Les facteurs qui permettent de faciliter la tache (les algorithmes sont très faciles à comprendre et disponibles en ADA par exemple).  Les fonctions et les performances doivent être évaluées ensemble. Fonctions et performances sont en fait intimement liées.  Le logiciel interagit avec les autres éléments du système. Il faut donc considérer la nature de la complexité de chaque interface pour déterminer les effets sur le développement des ressources, le coût et le délai.  L’aspect le moins précis de la portée du logiciel est la fiabilité. La nature du logiciel impose une considération particulière pour assurer la fiabilité. Par exemple la fiabilité d’un système de contrôle aérien ou d’un système de surveillance spatiale diffère de celle d’un système de contrôle d’inventaire ou d’un traitement de texte.

  Si la spécification d’un système est proprement développée (ou presque), toutes les informations nécessaires pour la description de la portée d’un logiciel seront disponibles et documentées avant de commencer le plan du logiciel. Remarque : du moment que le coût et le délai sont orientés fonctions, un certain degré de décomposition (fonctionnelle) serait utile.

Les ressources

  La deuxième étape du plan du Logiciel est l’estimation des ressources nécessaires pour accomplir l’effort du développement du logiciel (la première étape étant la portée du logiciel). Chacune des ressources est spécifiée selon quatre caractéristiques:  

La description de la ressource La disponibilité de la ressource



La date chronologique pendant laquelle la ressource est nécessaire

SPECIFIER:  Description  Disponibilité  Durée  Date de livraison RESSOURCES HUMAINES HARDWARE/SOFTWARE SPECIFIER: - Compétence Nécessaire - Disponibilité - Durée - Date de Commencement OUTILS Pour supporter l’effort de développement

Métriques pour la qualité et la productivité du Logiciel

 C’est un éventail très large de mesures pour les systèmes informatiques dont le but est de mesurer la productivité.  Les mesures de productivité sont donc des mesures des résultats d’un développement de logiciel en fonction de l’effort dépensé.

Mesure de logiciel

 Le logiciel est mesuré pour plusieurs raisons:      (1) pour indiquer la qualité du produit (2) pour évaluer la productivité des personnes ayant réalisé le produit (3) pour évaluer les avantages (productivité, qualité) obtenus en appliquant de nouvelles méthodes et de nouveaux outils pour le génie logiciel. (4) pour avoir une base pour l’estimation (5) pour aider à justifier la demande pour de nouveaux outils ou de nouveaux apprentissages.

 Les métriques pour le logiciel peuvent être classées de deux manières: les mesures directes et les mesures indirectes.

Les mesures Directes

 Elles sont relativement faciles à obtenir et regroupent:        Le coût L’effort Nombres de Lignes de Code (LOC) La vitesse La taille mémoire Les erreurs ……

Les Mesures Indirectes

 Elles sont plus difficiles à obtenir et regroupent:        La fonction La qualité La complexité L’efficacité La fiabilité La maintenabilité ….

 Au lieu de considérer le processus de développement du logiciel, on peut classer les métriques du logiciel en:   Les métriques orientées taille: elles sont obtenues directement et permettent de mesurer la qualité et les résultats du logiciel Les métriques orientées fonctions: ce sont des mesures indirectes

Les Métriques Orientées Taille

  Ce sont des mesures directes du logiciel et du processus de développement de ce logiciel. Une table de données orientées taille peut être créée.  La table donne, pour chaque projet, les données orientées taille correspondantes.



PROJECT EFFORT D.A LOC PGS-DOC ERREURS

  

AAA-01 24 840 12.1 365 29 3 CCC-04 62 2200 27.2 1224 86 5 FFF-O3 43 1570 20.02 1050 64 6 PERS.

  Pour Le projet AAA-01,  12,1 Kilos (1000) de lignes de codes ont été développés     avec un effort de 24 Personnes/Mois à un prix de 840.000 D.A. 365 pages de documentations ont été fournies et 29 erreurs ont été détectées après une année d’utilisation du logiciel. L’effort et le coût enregistrés dans la table représentent toutes les activités du logiciel (Analyse, Conception, Code et Test).

 A partir de cette table, un ensemble de métriques simples orientées taille de la productivité et de la qualité peuvent être calculées pour chaque projet 1.

2.

3.

4.

PRODUCTIVITE=KLOC / PERSONNE-MOIS QUALITE = ERREUR / KLOC COUT = D.A / KLOC DOC = PGS-DOC / KLOC (1) (2) (3) (4)

  Les Métriques Orientées Taille ne sont pas universellement acceptées comme le meilleur moyen de mesurer le processus de développement de logiciel. La raison est l’utilisation des LOC (langage dépendante) comment mesure clé.

Les Métriques Orientées Fonction

     Ce sont des mesures indirectes du logiciel. Au lieu de calcules le nombre de lignes de code (LOC), les métriques orientées fonction se basent sur la « fonctionnalité » et « l’utilité » du logiciel. Une méthode appelée Fonction Point est utilisée. Elle consiste à calculer des points fonction à partir d’une relation empirique basée sur des mesures quantifiables du domaine d’information du logiciel et des évaluations subjectives de la complexité du Logiciel. Cette méthode est utilisée dans des applications de gestion et n’est pas adéquate pour des applications de contrôle

  Les Fonctions Point (FP) seront calculées en complétant la table ci-dessous. Cinq caractéristiques du domaine d’information seront utilisées

Nombre d’entrées de l’utilisateur (différentes des demandes): ce sont les entrées qui fournissent des applications distinctes orientées données. Nombre de sorties de l’utilisateurs pour les applications orientées information Nombre de demandes de l’utilisateur - Nombre de fichiers internes Nombre d’interfaces externes (fichiers externes: Données sur bande)

 Une valeur de complexité est associée avec chaque compte en se basant sur des critères subjectifs. FP = COMPTE.TOTAL x [ 0.65 + 0.01 x SOMME (Fi) ] (5) ou: Fi (i = 1 à 14) sont des valeurs de correction de la complexité en se basant sur les réponses (au nombre de 14) aux questions telles que: Est ce que le système a besoin d’un moyen fiable de sauvegarde et de reprise Est ce que la communication des données est nécessaire - Est ce que il existe des fonctions de traitement distribuées...

 Les questions seront notées sur un intervalle de 0 à 5: 0 aucun effet 1 effet très faible 2 effet modéré 3 effet moyen 4 effet signifiant 5 effet essentiel

      

Product attributes

a. required software reliability b. size of application data base c. complexity of the product 2.

Hardware attributes

    a. run-time performance constraints b. memory constraints c. volatility of the virtual machine environment d. required turnaround time 3.

Personnel attributes

     a. analyst capability b. software engineer capability c. applications experience d. virtual machine experience e. programming language experience 4.

Project attributes

   a. use of software tools b. application of software engineering methods c. required development schedule

 Une fois que les FP sont calculées, elles seront utilisées (comme dans le cas des LOC) comme mesure de productivité, de qualité et d’autres attributs du logiciel.

PRODUCTIVITE = FP / PERSONNE-MOIS QUALITE = ERREUR / FP COUT = D.A / FP DOCUMENTATION = PGS-DOC / FP (6) (7) (8) (9)

Avantages et Inconvénients

  Les avantages sont:  L’indépendance vis-à-vis du langage  L’utilisation de données qui sont très probables d’être connues très tôt. Ses inconvénients sont:   La subjectivité La difficulté d’obtenir des données (pas de moyens physiques).

  En fait les deux méthodes FP et LOC ont des avantages et des inconvénients et les données peuvent être obtenues à partir de projets passés. Les moyennes calculées avec les données historiques en conjonction avec les estimations LOC ou FP pour un nouveau projet fournissent des estimations de coût ou d’effort.

Exemple

 les données ci-dessous indique que:  Une Ligne de Code de PL1 fournit presque deux fois la fonctionnalité (en moyenne) qu’une Ligne de Code de COBOL.  Une Ligne de Code de 4GL fournit entre deux et quatre fois la fonctionnalité d’une Ligne de Code d’un Langage de Programmation classique.

 LANGAGE LOC/FP COBOL 110 PL1 65 4GL 25

   Peut on comparer LOC/PM (ou FP/PM) d’un groupe avec des données similaires d’un autre groupe?

La réponse est non. Plusieurs facteurs influent sur la productivité entre autres:      Les facteurs humains: la taille et l’expertise Les facteurs liés aux problèmes: la complexité et les changements Les facteurs liés aux processus: l’analyse et la conception Les facteurs liés aux produits: la fiabilité et la performance Les facteurs liés aux ressources

Unité de charge

    La charge est la quantité de travail exprimée en ressources temps.

Les ressource sont souvent des hommes Le temps est  Le mois pour les grands projets,  Le jour pour les petits projets.

La charge est souvent pondérée par coefficient de productivité  Exemple : 10 jours x hommes    1 homme pendant 10 jours 10 hommes pendant 1 jour 5 hommes pendant 2 jours

Unité de charge corrigée

Exemple de correction de productivité:    jours ouvrables jo = 52 x 5 = 260 jours fériés congés 12 30  maladie 3   formation réunions 4 6  nb jours improductifs (ji) = 55

Estimer les coûts

Estimation du Logiciel

   L’estimation du coût et de l’effort de développement d’un logiciel n’est jamais une science exacte.

Il y’ a plusieurs variables qui entrent en jeu: humaine, technique, environnement, etc. On a quatre options pour mener des estimations fiables du coût et de l ’effort:   (1) Reporter l’estimation au plus tard (l’estimation est à 100% correcte lorsque le projet est terminé). (2) Utiliser « les techniques de Décomposition » pour générer des estimations du coût et de l’effort d’un projet.   (3) Développer des modèles Empiriques pour le coût et l’effort de logiciels. (4) Acquérir un ou plusieurs outils automatiques

 La première option n’est pas pratique.  Les techniques de décomposition utilisent l’approche « Diviser pour Régner ».  Les estimations sont calculées d’une manière graduelle.

 Les modèles d’estimation empiriques peuvent être utilisés pour compléter la technique de décomposition.

 Le modèle est basé sur des expériences et prennent la forme: d = f (Vi) où d est la valeur estimée et Vi sont les paramètres.  Les outils automatiques d’estimation implémentent une ou plusieurs méthodes

Les Techniques de Décomposition

  LOC et FP constituent les données de base à partir desquelles on peut calculer les métriques de productivité (Voir équations 1, 2,3,4, 5, 6, 7, 8 et 9). LOC et FP sont utilisées comme:  Des variables d’estimation utilisées pour avoir la taille de chaque élément du logiciel.  Base de métriques pour obtenir des données sur des projets anciens en conjonction avec les variables d’estimation pour développer des projections sur le coût et l’effort.

 Les techniques d’estimation LOC et FP diffèrent sur le niveau de détail nécessaire pour la décomposition du Logiciel en de petites sous fonctions qui peuvent être estimées individuellement.  La technique LOC demande plusieurs niveaux de détail.  Par contre la technique FP demande moins de détails.

 La technique FP est déterminée indirectement en estimant  le nombre d’entrées,  le nombre de sorties,    le nombre de demandes, le nombre de fichiers de données et le nombre d’interfaces  aussi bien que les 14 valeurs de correction de la complexité

   Pour chaque fonction, l’analyste donne  une estimation optimiste,  la plus probable et  pessimiste des valeurs LOC ou FP en utilisant l’intuition ou les données historiques. Le nombre moyen ou espéré de LOC ou FP est calculé selon la formule (distribution BETA) et qui constitue une moyenne équilibrée des valeurs optimiste, plus probable et pessimiste des valeurs LOC ou FP: E = ( a + 4m + b) / 6 (10)

  Exemple Logiciel pour développer des applications CAD (Conception Assistée par Ordinateur). En étudiant les spécifications du système, on a trouvé que le logiciel doit s’exécuter sur une station de travail et doit être avoir une interface avec:  - Une souris,    - Un Digitizer, Un écran couleur grande résolution et Une imprimante grande résolution. 

        La variable d’estimation utilisée est LOC (on peut aussi bien utiliser FP en estimant les domaines d’information). Le sous fonctions majeures sont: Interface Utilisateur et Contrôle des Facilités (UICF) Analyse géométrique à deux dimensions (2DGA) Analyse géométrique à trois dimensions (3DGA) Gestion des Structures de Données (DSM) Facilités d’affichage Graphiques (CGDF) Contrôle de Périphérique (PC) Modules d’analyse des affichages (DAM).

     La technique de décomposition consiste à: Développer les estimations des LOC (les intervalles de valeurs) calculer la valeur espérée pour chaque sous fonction. Une estimation de 33360 Lignes de Code est établie pour le système CAD. Les métriques de productivité (dérivées à partir d’une base de données historique) sont obtenues pour D.A/LOC et LOC / PM. L’analyste utilise des métriques de productivité différentes pour chaque sous fonction en se basant sur le degré de complexité. Les colonnes Coût et Mois de la table seront déterminées en multipliant ou en divisant les LOC (espérées) avec D.A/LOC et LOC/PM respectivement. Le total est de 657000 D.A et 145 Personnes-Mois.

L’estimation de l’effort

 C’est la technique la plus utilisée pour déterminer le coût de développement d’un projet.  L’estimation de l’effort commence par déterminer les fonctions du logiciel obtenues à partir de la portée du logiciel.  Une série de taches doivent être effectuées pour chaque fonction (analyse des besoins, conception, code et test).

 Pour chacune des fonctions logicielles, l’analyste évalue l’effort (PM par exemple) nécessaire pour accomplir chacune des taches du Génie Logiciel.  Le coût et l’effort de chaque fonction du logiciel seront calculés en dernier lieu.  Si l’estimation de l’effort est calculée indépendamment de l’estimation de LOC et FP, on aura deux estimations du coût et de l’effort qui pourront être comparées.

Modèles Empiriques d’estimation

Le modèle d’estimation utilise de formules dérivées empiriquement pour prévoir les données nécessaires et constitue une partie de l’étape de plan du logiciel.  Ces formules sont dérivées à partir d’un ensemble limité de projets.   Le modèle de ressources est constitué d’une ou plusieurs équations dérivées empiriquement et qui prévoient  l’effort (PM),   la durée du projet, et/ou les autres données du projet. Il y ’a 4 classes de modèles de ressources:     Modèles Statiques à une seule variable, Modèles Statiques à variables Multiples, Modèles dynamiques à variables Multiples et Modèles Théoriques

Modèles Statiques avec une seule variable:

 RESSOURCE = C1 X ( CARACTERISTIQUES ESTIMEES ) c2, ou  RESSOURCE peut être:     EFFORT (PM), DUREE DU PROJET (D), TAILLE DU PERSONNEL (S), DOC...

  C1 et C2 sont dérivées à partir de données sur des projets anciens. Les caractéristiques estimées sont:    Lignes de code source, l’effort et d’autres caractéristiques...

Exemple

 En se basant sur 60 projets de tailles entre 4000 et 4670000 de lignes de code avec un effort de 12 à 11758 Personnes-Mois, les modèles suivant ont été dérivés:         E = 5.2 X L0.91

D = 4.1 X L0.36

D = 2.47 X E0.35

S = 0.54 X E0.06

DOC = 49 X L1.01

ou L est le nombre estimé de Lignes de code source (en milliers), E l’effort dérivé en Personnes-Mois et D la durée en Mois.

Modèles Statiques à Variables Multiples

  Ces modèles utilisent des données historiques pour dériver des relations empiriques. Un modèle type de cette catégorie prend la forme:  RESSOURCE = C11 x e1 + C21 x e2 + ....

 ei est la ieme caractéristique et  Ci1 et Ci2 sont des constantes dérivées empiriquement pour la ieme caractéristique

Le Modèle Dynamique à variables Multiples

   Dans ce modèle les besoins en ressources sont exprimés en fonction du temps. Si le modèle est dérivé empiriquement, les ressources seront définies en une série d’intervalles de temps qui alloue un pourcentage de l’effort (ou autres) pour chaque étape dans le processus du Génie Logiciel modèle PUTNAM par exemple.