La technique d’estimation à 3 points:
𝑑𝑢𝑟é𝑒(𝑥) =𝑑𝑜(𝑥)+4𝑑𝑚(𝑥)+𝑑𝑝(𝑥)/6
l’écart-type : 𝑆𝐷(𝑥)=𝑑𝑜(𝑥)−𝑑𝑝(𝑥)/6.
La variance : 𝑉(x)=𝑆𝐷(x)2
L’erreur standard de la durée estimée du
projet est : 𝑆̅=√Σ𝑉(𝑥)
Cette mesure fournit une indication sur la
fiabilité des mesures estimées. Plus elle
est grande, plus la variation entre nos
estimations et la réalisation peut être
grande, ce qui peut refléter une
incertitude dans la planification du projet.
Modèle COCOMO basique :
Modèle statique rapide
Dépend uniquement du nombre de lignes
de code
𝐸 = 𝑎 × 𝐾𝐿𝑂𝐶𝑏 MH
• E: effort total requis pour le projet (en
mois-homme MH)
• D: durée totale requise pour réaliser le
projet (en mois M)
• P: nombre de personnes requises pour
réaliser le projet
• KLOC: taille du code (en mille lignes
de codes)
𝐷 = 𝑐 × 𝐸𝑑 M
𝑃 = 𝐸/𝐷
Organic 2.4/1.05 /2.5 /0.38
Semi-detached 3 /1.12/ 2.5/ 0.35
embedded 3.6/1.2 /2.5/0.32
Modèle COCOMO intermédiaire :
Extension du modèle COCOMO basique
Modèle plus précis
Prend en considération: produit, matériel,
ressources et paramètres du projet
𝐸 = 𝑎 × 𝐾𝐿𝑂𝐶𝑏 × 𝐸𝐴𝐹
EAF: Effort Adjustment Factor
Modèle COCOMO détaillé (complet)
Combine les avantages de cocomo
basique et cocomo intermédiaire
Le logiciel est divisé en plusieurs
modules, et cocomo est appliqué sur
chaque module pour estimer l’effort, puis
somme ces efforts pour calculer
l’effort global.
Les 6 phases de COCOMO détaillé:
• Planification et exigences
• Conception du système
• Conception détaillée
• Code et test
• Intégration et test
• COCOMO
Les stages du modèle COCOMO II
prend en charge l'estimation du
prototypage.
prend en charge l'estimation au début de
la phase de conception du projet, lorsque
l'on en sait moins.
prend en charge l'estimation dans la
phase post-architecture du projet
T/objet Poids de la complexité
Simple Moyen Difficile
écran 1 2 3 exigences que nous avons.
rapport 2 5 8 La vérification est liée aux tests statiques.
Comp- - - 10
3GL
Déterminer les points d'objet
Ajouter toutes les instances d'objet
pondérées pour obtenir un nombre, ce
que l'on appelle le nombre de points
d'objet.
Point d'objet = Somme (nombre
d'instances d'objet) * (Poids de
complexité de chaque instance d'objet)
Calculer les nouveaux points d'objet
(NOP)
Nous devons estimer le pourcentage de
réutilisation à réaliser dans un projet, en
fonction du pourcentage de réutilisation:
NOP = [(points objet) * (100 - %
réutilisation)]/100
Expérience productivité
dév (PROD)
Très faible 4 d'essais. Les tests alpha peuvent
Faible 7 nécessiter un cycle plus long, permettant
Nominale 13
Grande 25
Très grande 50
L’effort est estimé par:
E = NOP / PROD
Les tests statiques, effectués en boîte
blanche, consistent en une vérification
ligne par ligne du code par le
programmeur avant son transfert à
l'ingénieur de test. Que ce soit
manuellement ou à l'aide d'outils, ces
tests visent à détecter les erreurs dès les
premières étapes du développement, ce
qui en fait un processus de vérification.
Les activités de vérification comprennent
l'examen de documents, la revue de la
conception à haut et bas niveau, ainsi que
l'examen détaillé du code, contribuant
ainsi à améliorer la qualité de
l'application.
Les tests dynamiques sont exécutés
lorsque le code est en cours d'exécution
dans l'environnement d'exécution. Cela
constitue un processus de validation
englobant des tests fonctionnels tels que
les tests unitaires, d'intégration et de
système, ainsi que des tests non
fonctionnels comme les tests
d'acceptation utilisateur. L'objectif des
tests dynamiques est de vérifier que
l'application ou le logiciel fonctionne
correctement tant pendant qu'après son
installation, sans présenter d'erreurs.
Comparaison :
Les tests statiques se concentrent sur la
vérification du code ou de l'application
sans son exécution, impliquant des
activités telles que la révision du code et
la procédure pas à pas. Ces tests sont un
processus de vérification visant à
prévenir les défauts.
À l'inverse, les tests dynamiques
vérifient le code ou l'application en
l'exécutant, impliquant des activités telles
que les tests fonctionnels (unitaires,
d'intégration, système) et non
fonctionnels (utilisabilité, acceptation
utilisateur). Ils sont un processus de
validation visant à rechercher et corriger
les défauts pendant et après l'installation.
---------
La vérification est le processus
permettant de vérifier que le logiciel
atteint son objectif sans aucun bug. C'est
le processus permettant de garantir si le
produit développé est correct ou non. Il
vérifie si le produit développérépond aux
L'objectif de la vérification est de
s'assurer que le logiciel est conforme aux
spécifications.
La validation est le processus permettant
de vérifier si le produit logiciel est à la
hauteur ou, en d'autres termes, si le
produit a des exigences de haut niveau.
C'est le processus de vérification de la
validation du produit, c'est-à-dire qu'il
vérifie que ce que nous développons est
le bon produit. c'est une validation des
produits réels et attendus.
La validation est liée aux tests
dynamiques. Son objectif est de vérifier
si le logiciel répond ou non aux exigences
et aux attentes du client
Comparaison :
La vérification se concentre sur la
vérification des documents, de la
conception, des codes et des programmes,
impliquant des activités telles que les
examens, les vérifications pas à pas, les
inspections et les vérifications
documentaires. Elle vise le processus, les
normes et les lignes directrices sans
inclure l'exécution du code, retrouvant
environ 50 à 60% des défauts.
En revanche, la validation se concentre
sur le test et la validation du produit réel,
incluant l'exécution du code. Les
méthodes utilisées pour la validation sont
les tests Black Box, White Box et les
tests non fonctionnels. La validation
concerne le produit et retrouve environ 20
à 30% des défauts.
Les tests alpha sont une phase initiale de
tests logiciels effectuée par l'équipe de
développement interne avant la mise à
disposition du produit aux utilisateurs
réels ou au public. Ces tests font partie
des tests d'acceptation des utilisateurs et
visent à identifier et corriger les bugs,
failles et problèmes d'utilisabilité. Les
testeurs alpha, principalement des
membres de l'équipe de développement,
interviennent dans un environnement de
développement ou un laboratoire
similaire aux paramètres réels. L'objectif
principal des tests alpha est de garantir la
qualité du logiciel avant sa diffusion plus
large.
Les tests bêta impliquent l'utilisation
réelle de l'application par de vrais
utilisateurs dans un environnement réel
avant la sortie officielle du produit. Ces
tests sont considérés comme des tests
d'acceptation des utilisateurs, où une
version préliminaire est mise à la
disposition d'un groupe sélectionné
d'utilisateurs ou de clients externes,
élargissant ainsi la participation aux tests.
L'objectif des tests bêta est d'obtenir les
avis des utilisateurs réels afin de détecter
les bugs, les difficultés d'utilisation et les
domaines nécessitant des améliorations
avant la sortie officielle. Les bêta-
testeurs, un groupe plus vaste et varié,
sont invités à participer, et les tests se
déroulent dans un environnement utilisant
les paramètres du monde réel.
Comparaison :
Les tests alpha et bêta représentent deux
phases distinctes du processus de tests
logiciels. Les tests alpha, réalisés en
interne par des testeurs sur le site du
développeur, visent à assurer la qualité du
produit en combinant des méthodes en
boîte blanche et en boîte noire. En
revanche, les tests bêta, effectués par des
clients externes chez les utilisateurs
finaux, évaluent la fiabilité et la sécurité
du produit, tout en recueillant des
commentaires pour des améliorations. En
synthèse, les tests alpha garantissent la
qualité avant la diffusion, tandis que les
tests bêta tirent parti de l'expérience des
utilisateurs pour peaufiner le logiciel
avant sa sortie officielle. Les différences
significatives entre ces deux phases
résident dans la durée d'exécution, la
gestion des problèmes et les cycles
aux développeurs de résoudre
immédiatement les problèmes critiques.
À l'inverse, les tests bêta, souvent de
courte durée, intègrent les commentaires
des utilisateurs dans des versions futures,
illustrant une approche plus itérative et
axée sur l'utilisateur final.
Les tests en boîte noire, aussi appelés
tests fonctionnels, représentent une
approche du test logiciel où la
fonctionnalité interne du logiciel n'est pas
connue. Ces tests sont réalisés sans une
connaissance détaillée des aspects
internes du produit. L'accent est mis sur
les attributs et le comportement externes
du logiciel, examinant son
fonctionnement attendu du point de vue
de l'utilisateur.
Les tests en boîte blanche, également
appelés tests structurels ou tests non
fonctionnels, constituent une méthode de
test logiciel basée sur la connaissance des
structures de données internes, du flux
logique physique et de l'architecture au
niveau du code source. Ces tests sont
orientés vers le point de vue du
développeur, examinant le logiciel en se
concentrant sur ses composants internes.
Les tests de boîte grise combinent les
approches de test de boîte noire et de
boîte blanche. Cette méthode est
particulièrement adaptée aux tests
d'applications Web, car elle prend en
considération un environnement de
conception de haut niveau ainsi que les
conditions d'interopérabilité.
Comparaison :
Les tests de boîte noire sont réalisés
sans connaître les détails internes du
logiciel, adaptés aux tests fonctionnels.
Ils offrent une résilience et une sécurité
contre les attaques virales.
Les tests de boîte grise combinent des
aspects de boîte noire et de boîte blanche,
nécessitant une connaissance partielle des
éléments internes. Ils conviennent aux
tests approfondis de domaines
fonctionnels mais ne garantissent pas la
résilience ni la sécurité contre les attaques
virales.
Les tests de boîte blanche, effectués par
des développeurs avec une connaissance
approfondie du code interne, conviennent
à tous les types de tests et permettent une
couverture logique. Cependant, ils ne
fournissent pas de résilience ni de
sécurité contre les attaques virales.
Chaque approche de test présente des
avantages spécifiques en fonction des
besoins du projet.
Le test global vise à assurer que le
système ou l'application logicielle peut
fonctionner de manière efficace dans tous
les environnements culturels ou locaux.
Dans le cadre de la mondialisation, ce
type de test examine divers aspects de
l'application pour garantir sa prise en
charge de toutes les langues et de
différents attributs.
Le test local est réalisé pour évaluer un
système ou une application logicielle
dans un environnement géographique et
culturel spécifique. Un produit localisé
est conçu pour prendre en charge un type
de langue spécifique et est utilisable
exclusivement dans une région
particulière.
1- La validation du logiciel vérifie
principalement les incohérences entre :
c) Spécifications détaillées et exigences
des utilisateurs
2- Quel type de test est généralement
associé à la vérification des logiciels ?
a) Tests de régression
3. Déterminer si vous avez
correctement construit le système
s’appelle :
a) Vérification du logiciel
4. Dans une application Web, quel test
recommanderiez-vous à une équipe de
développeurs que vous venez de
recruter ?
b) Test en boîte grise
l'ingénierie inverse, un processus
complexe visant à extraire des
informations de conception, des
spécifications et des fonctions à partir de
l'analyse du code existant. Ce processus
se révèle précieux pour réduire les coûts
de développement, analyser la sécurité,
intégrer des composants, récupérer du
code source perdu et effectuer la
correction des bogues.
les technologies d'optimisation pour le
Génie Logiciel, mettant en évidence le
"Search-Based Software Engineering"
(SBSE). Cette approche novatrice utilise
des techniques d'optimisation pour
automatiser des aspects clés du
développement logiciel, tels que
l'optimisation des processus, du code
source, et la gestion des ressources.
Se repose sur des fondements théoriques
tels que les algorithmes génétiques,
la recherche tabou, les algorithmes de
colonies de fourmis, ainsi que sur la
représentation du code source et des
configurations logicielles. Cette approche
s'avère précieuse pour identifier des
optimisations possibles, automatiser la
réécriture de code, générer des jeux de
tests, localiser des bugs et faciliter la mise
à jour automatique du logiciel.
Question TP
1- Le génie logiciel a été créé en réponse
à deux besoins majeurs dans le
développement de logiciels :
Complexité croissante des logiciels :
Avec la croissance exponentielle de la
complexité des systèmes logiciels, il
devenait impératif d'adopter des
méthodes et des processus systématiques
pour concevoir, développer, tester et
maintenir des logiciels de manière
efficace.
Problèmes de qualité et de coût : Les
défis liés à la qualité des logiciels, tels
que les bugs, les retards et les coûts
imprévisibles, ont conduit à la nécessité
d'appliquer des principes d'ingénierie
dans le processus de développement
logiciel. Le génie logiciel vise à fournir
des approches structurées et des
méthodologies pour améliorer la qualité
des logiciels tout en maîtrisant les coûts
et les délais.s
Différences entre XP (eXtreme
Programming) et RAD (Rapid Application
Development) en termes de taille des équipes
et de taille des projets :
-Taille des équipes :
XP : XP encourage généralement des
équipes de petite à moyenne taille. Les
équipes sont souvent composées de 5 à
12 membres, favorisant la
communication étroite et la collaboration
intensive entre les membres.
RAD : RAD peut être adaptatif à
différentes tailles d'équipes, mais il est
souvent utilisé dans des contextes où des
équipes plus importantes peuvent être
impliquées. Les équipes peuvent varier en
taille, avec une flexibilité permettant
d'ajuster la composition en fonction des
besoins du projet.
- Taille des projets :
XP : Conçu initialement pour des projets
de petite à moyenne envergure, XP peut
être moins adapté aux projets de grande
envergure en raison de son approche axée
sur la communication et l'interaction
directe.
RAD : RAD a été développé pour
accélérer le processus de développement,
ce qui le rend potentiellement approprié
pour des projets de taille moyenne à
grande, où une mise en œuvre rapide est
essentielle. La flexibilité de RAD permet
de gérer des projets de différentes tailles
et de s'adapter à des besoins changeants.
Le plan qualité et le manuel qualité sont
deux documents essentiels dans le
domaine de la gestion de la qualité,
chacun jouant un rôle distinct au sein
d'une organisation ou d'un projet.
3- Le **plan qualité** agit comme une
feuille de route spécifique à un projet,
détaillant les étapes et les procédures qui
seront suivies pour garantir que les
objectifs qualité du projet seront atteints.
Il aborde des aspects tels que les normes
de qualité applicables, les méthodes de
contrôle et d'assurance qualité, les
responsabilités des membres de l'équipe,
les ressources nécessaires, et d'autres
activités liées à la qualité. En somme, il
offre un cadre détaillé pour la gestion de
la qualité tout au long du projet.
D'un autre côté, le **manuel qualité**
offre une perspective plus large, couvrant
l'ensemble de l'organisation. Il expose la
politique qualité de l'entreprise, décrivant
ses engagements envers la qualité et
présentant les procédures établies pour
assurer la conformité aux normes de
qualité. Ce document aborde des aspects
tels que la structure organisationnelle, les
responsabilités, les processus clés, et la
manière dont l'organisation répond aux
exigences légales et réglementaires.
Contrairement au plan qualité, le manuel
qualité n'est pas spécifique à un projet
donné, mais offre une vision globale de la
manière dont la qualité est intégrée dans
toutes les activités de l'entreprise.
le plan qualité se concentre sur les
détails spécifiques d'un projet, tandis que
le manuel qualité offre une vision
holistique de la politique qualité de
l'organisation dans son ensemble.
Ensemble, ces documents contribuent à
assurer la qualité des produits ou services
livrés tout en respectant les normes et les
engagements de l'organisation.
Exemple 9 :
1.Diversité des Plateformes (Linux et
Windows) :**
-Domaine : Déploiement technique.
-Risques : Les équipes peuvent
rencontrer des difficultés en raison de la
diversité des plateformes, ce qui pourrait
entraîner des retards.
- Solutions : - Réaliser une analyse
approfondie des spécifications techniques
de chaque plateforme.-Mettre en place
des environnements de test représentatifs
des plateformes cibles.-Assurer une
communication et une formation claires
sur les particularités de chaque
plateforme.
2.Manque d'Informations sur
l'Environnement P6 :**
- Domaine : Gestion des informations.
- Risques :L'absence d'informations
détaillées sur l'environnement P6 peut
entraîner des incertitudes et des erreurs
lors de la mise en place.
- Solutions : - Engager des discussions
avec le client pour obtenir des
informations détaillées sur
l'environnement P6.- Mener une
évaluation approfondie de la
compatibilité de P6 avec les plateformes
cibles.- Allouer du temps pour des tests
pilotes afin de valider la configuration.
3. Difficulté d'Adaptation des Équipes
du Client :
-Domaine: Facteur humain et
organisationnel.
-Risques : La résistance au changement
peut entraîner une adoption lente ou des
retards dans la mise en œuvre.
- Solutions : - Organiser des sessions
de sensibilisation et de formation pour les
équipes du client. - Impliquer activement
les membres clés du client dans le
processus de planification. - Mettre en
place un support technique dédié pour
résoudre rapidement les problèmes
rencontrés par les équipes.