Software Engineering

Traduit de Anglais vers Français - www.onlinedoctranslator.
com
Génie logiciel
Didacticiel
Apprentissage tout simplement facile
A propos du tutoriel
Tutoriel de génie logiciel

Ce didacticiel vous fournit les connaissances de base sur les produits logiciels, le processus
de conception et de développement de logiciels, la gestion de projets logiciels et les
complexités de conception. À la fin du didacticiel, vous devriez être équipé d'une bonne
compréhension des concepts de génie logiciel.
Public
Ce tutoriel est conçu pour les lecteurs poursuivant une formation en développement de logiciels
domaine et tous les lecteurs enthousiastes.
Conditions préalables
Ce tutoriel est conçu et développé pour les débutants absolus. Cependant, une connaissance des
systèmes logiciels, du processus de développement de logiciels et des principes fondamentaux de
l'informatique serait bénéfique.
Droits d'auteur et clause de non-responsabilité
-Copyright 2014 par Tutoriels Point (I) Pvt. Ltd.
Tout le contenu et les graphiques publiés dans cet e-book sont la propriété de Tutotorials Point (I)
Pvt. Il est interdit à l'utilisateur de cet e-book de réutiliser, conserver, copier, distribuer ou republier
tout ou partie du contenu de cet e-book de quelque manière que ce soit sans le consentement écrit
de l'éditeur.
Nous nous efforçons de mettre à jour le contenu de notre site Web et de nos tutoriels aussi rapidement et aussi
précisément que possible, cependant, le contenu peut contenir des inexactitudes ou des erreurs. Point Tutoriels (
JE)Pvt. Ltd. ne fournit aucune garantie concernant l'exactitude, l'actualité ou l'exhaustivité de notre site Web ou
de son contenu, y compris ce didacticiel. Si vous découvrez des erreurs sur notre site Web ou dans ce tutoriel,
veuillez nous en informer àcontact@tutorialspoint.com
Table des matières
TUTORIEL D'INGÉNIERIE LOGICIELLE .................................................. ..............................................JE
PUBLIC................................................. .................................................. ..................................JE
CONDITIONS PRÉALABLES ................................................. .................................................. ..........................JE
DROITS D'AUTEUR ET AVIS DE NON-RESPONSABILITÉ............................................ .................................................. ...........JE
APERÇU DU LOGICIEL ................................................................ .................................................. ...............1

DÉFINITIONS.................................................. .................................................. .......................................1
SLOGICIELEVOLUTION.................................................. .................................................. .......................2
SLOGICIELEVOLUTIONLAWS.................................................. .................................................. ................3
HEÉVOLUTION DU LOGICIEL YPE.................................................. .................................................. ..............3
SLOGICIELPARADIGMES.................................................. .................................................. .......................4
Paradigme de développement logiciel .................................................................. .................................................. ..4
Paradigme de conception de logiciel .................................................. .................................................. ............5
Paradigme de programmation .................................................. .................................................. ................5
NNÉCESSAIRE DESLOGICIELEINGÉNIERIE.................................................. .................................................. .........5
CCARACTERISTIQUES D'UN BON LOGICIEL.................................................. .................................................. ...6
Opérationnel .................................................. .................................................. ..................................6
Transitionnel .................................................. .................................................. ..................................6
Entretien ................................................. .................................................. ................................6
CYCLE DE VIE DU DEVELOPPEMENT DU LOGICIEL .................................................. ................................................8
SDLC ACTIVITÉS.................................................. .................................................. ..................................8
Communication ................................................. .................................................. ................................8
Recueil des besoins .................................................................. .................................................. ................8
Étude de faisabilité ................................................ .................................................. ................................9
L'analyse du système ................................................ .................................................. .............................9
Conception de logiciels ................................................ .................................................. ................................9
Codage ................................................................ .................................................. .......................................9
Essai................................................. .................................................. .......................................9
L'intégration ................................................. .................................................. .................................dix
Mise en œuvre................................................. .................................................. ..........................dix
Opération et maintenance............................................... .................................................. ........dix
SLOGICIELDDÉVELOPPEMENTPARADIGM.................................................. .................................................. ..dix
Modèle de cascade .................................................. .................................................. ..........................dix
Modèle itératif .................................................. .................................................. ................................11
Modèle en spirale .................................................. .................................................. ................................12
V – modèle .................................................. .................................................. .....................................12
Modèle Big Bang .................................................. .................................................. ................................14
GESTION DE PROJET LOGICIEL .................................................................. .................................................. 15

SLOGICIELPPROJET.................................................. .................................................. ................................15
NEED DE GESTION DE PROJET LOGICIEL.................................................. ..................................................15
SLOGICIELPPROJETMANAGER.................................................. .................................................. ...........16
Gérer des gens ................................................ .................................................. .......................16
je
Gestion de projet................................................................ .................................................. .......................17
SLOGICIELMGESTIONUNCTIVITÉS.................................................. .................................................. ..17
PPROJETPLANNER.................................................. .................................................. ..................................17
SSE DÉBROUILLERMGESTION.................................................. .................................................. .......................17
PPROJETESTIMATION.................................................. .................................................. .......................18
PPROJETESTIMATIONJTECHNIQUES.................................................. .................................................. ......19
Technique de décomposition .................................................. .................................................. ...........19
Technique d'estimation empirique .................................................. .................................................. ...19
PPROJETSPLANIFICATION.................................................. .................................................. .......................20
RGESTION DES ESOURCES.................................................. .................................................. ....................20
PPROJETRISKMGESTION.................................................. .................................................. ..............21
Processus de gestion des risques .................................................. .................................................. ...........21
PPROJETEXÉCUTION ETMSURVEILLANCE.................................................. .................................................. 21
PPROJETCCOMMUNICATIONMGESTION.................................................. .............................................22
CCONFIGURATIONMGESTION.................................................. .................................................. .........23
Ligne de base .................................................. .................................................. .......................................23
Le contrôle des changements................................................ .................................................. ................................23
PPROJETMGESTIONJOOLS.................................................. .................................................. ...........24
Diagramme de Gantt ................................................ .................................................. ..................................24
Diagramme PERT .................................................. .................................................. ....................................25
Histogramme des ressources .................................................. .................................................. .......................25
Analyse du chemin critique .................................................................. .................................................. .......................26
LOGICIELS REQUIS ................................................ .................................................. ..... 27

REXIGENCEEINGÉNIERIE.................................................. .................................................. ..............27
REXIGENCEEINGÉNIERIEPPROCESSUS.................................................. .................................................. .27
Étude de faisabilité................................................ .................................................. .......................27
Recueil des besoins .................................................................. .................................................. ...............28
Spécification des exigences logicielles (SRS) .................................................. .......................................28
Validation des exigences logicielles .................................................................. .................................................. 28
REXIGENCEELICITATIONPPROCESSUS.................................................. .................................................. ...29
REXIGENCEELICITATIONJTECHNIQUES.................................................. ..................................................29
Entrevues.................................................. .................................................. ....................................30
Enquêtes ................................................. .................................................. .......................................30
Questionnaire .................................................................. .................................................. .......................30
Analyse des tâches .................................................. .................................................. ...............................30
Analyse de domaine .................................................. .................................................. .......................30
Réflexion ................................................. .................................................. ................................30
Prototypage ................................................................ .................................................. ................................31
Observation................................................. .................................................. ................................31
SLOGICIELREXIGENCESCCARACTERISTIQUES.................................................. .......................................31
SLOGICIELREXIGENCES.................................................. .................................................. ................31
Exigences fonctionnelles ................................................................. .................................................. ............32
Prérogatives non fonctionnelles .............................................. .................................................. ......32
tuSÉRjeEXIGENCES D'INTERFACE.................................................. .................................................. .........33
SLOGICIELSSYSTÈMEUNANALYSTE.................................................. .................................................. ..............33
SLOGICIELMÉTRIQUE ETMMESURES.................................................. .................................................. ...34
ii
LES BASES DE LA CONCEPTION DU LOGICIEL .................................................. .................................................. ........ 36
SLOGICIELDSIGNATURELNIVEAUX.................................................. .................................................. ................36
MODULARISATION.................................................. .................................................. .............................37
CMONNAIE.................................................. .................................................. ..................................37
Exemple................................................. .................................................. .......................................37
COUBLAGE ETCOHESION.................................................. .................................................. ................38
COHESION.................................................. .................................................. .............................................38
COUBLAGE.................................................. .................................................. .......................................39
DSIGNATUREVÉRIFICATION.................................................. .................................................. .......................39
OUTILS LOGICIELS D'ANALYSE ET DE CONCEPTION......................................... ..................................... 41

DÀFFAIBLEDGRAPHIQUE.................................................. .................................................. .......................41
Types de DDF .................................................. .................................................. ................................41
Composants DFD.................................................................. .................................................. .......................41
Niveaux de DFD .................................................. .................................................. ................................42
SSTRUCTURECHARTS.................................................. .................................................. .......................43
HIPO DGRAPHIQUE.................................................. .................................................. ................................45
Exemple................................................. .................................................. .......................................46
SSTRUCTURÉEANGLAIS.................................................. .................................................. .......................47
Exemple................................................. .................................................. .......................................47
PSEUDO-CODE.................................................. .................................................. ..................................48
Exemple................................................. .................................................. .......................................49
DÉCISIONJCAPABLES.................................................. .................................................. ..............................49
Création d'une table de décision.............................................. .................................................. ................49
Exemple................................................. .................................................. .......................................50
Eentité-RL'ALLATIONMODEL.................................................. .................................................. .............50
DÀDICTIONNAIRE.................................................. .................................................. .............................51
Exigence du dictionnaire de données .................................................. .................................................. ...51
Contenu ................................................. .................................................. .....................................52
Exemple................................................. .................................................. .......................................52
Éléments de données .................................................. .................................................. .............................52
Magasin de données ................................................ .................................................. .......................................53
Traitement de l'information................................................ .................................................. .......................53
STRATÉGIES DE CONCEPTION DE LOGICIELS ....................................... .................................................. 54

SSTRUCTURÉDSIGNATURE.................................................. .................................................. .......................54
FONCTIONORIENTÉDSIGNATURE.................................................. .................................................. ..............55
Procédé de design................................................ .................................................. .............................55
OBJETORIENTÉDSIGNATURE.................................................. .................................................. ..................55
Procédé de design................................................ .................................................. .............................56
SLOGICIELDSIGNATUREUNAPPROCHES.................................................. .................................................. .........57
Conception descendante .................................................. .................................................. .......................57
Conception ascendante .................................................. .................................................. .......................57
CONCEPTION DE L'INTERFACE UTILISATEUR DU LOGICIEL ...................................... .................................................. 58

CCOMMANDELINEjeINTERFACE(CLI) ....................................................... .................................................. ...........58
Éléments CLI .................................................................. .................................................. ..................................59
iii
gRAPHIQUEtuSÉRjeINTERFACE.................................................. .................................................. ...............60
Éléments de l'interface graphique .................................................. .................................................. ..............................60
Composants de l'interface graphique spécifiques à l'application .................................. ...............................................61
tuSÉRjeINTERFACEDSIGNATUREUNCTIVITÉS.................................................. .................................................. .....62
IUG IMISE EN ŒUVREJOOLS.................................................. .................................................. .............64
Exemple................................................. .................................................. .......................................64
tuSÉRjeINTERFACEgRÈGLES ANCIENNES.................................................. .................................................. ..........64
COMPLEXITÉ DE LA CONCEPTION DU LOGICIEL ...................................... .................................................. 67

HAUSSI'SCOMPLEXITÉMMESURES.................................................. .................................................. ....67
CYCLOMATIQUECOMPLEXITÉMMESURES.................................................. .................................................. ..68
FONCTIONPOINT.................................................. .................................................. ..............................70
Entrée externe................................................ .................................................. ..............................70
Sortie externe ....................................................... .................................................. ................................71
Fichiers internes logiques.................................................. .................................................. .......................71
Fichiers d'interface externe.................................................. .................................................. ................71
Enquête externe .................................................................. .................................................. ................................71
MISE EN ŒUVRE DU LOGICIEL ....................................................... .................................................. 74

SSTRUCTURÉPPROGRAMMATION.................................................. .................................................. .............74
FUNCTIONNELPPROGRAMMATION.................................................. .................................................. ..............75
PSTYLE DE PROGRAMMATION.................................................. .................................................. .......................76
Consignes de codage .................................................. .................................................. .......................76
SLOGICIELDOBSERVATION.................................................. .................................................. .............77
SLOGICIELjeMISE EN ŒUVRECDÉFIS.................................................. .............................................78
VUE D'ENSEMBLE DES TESTS DE LOGICIELS ................................................. .................................................. 80

SLOGICIELVALIDATION.................................................. .................................................. .......................80
SLOGICIELVÉRIFICATION.................................................. .................................................. ....................80
MANUELVSUNUTILISÉJESTANT.................................................. .................................................. ......81
JESTANTUNAPPROCHES.................................................. .................................................. .......................81
Tests boîte noire .................................................. .................................................. .......................82
Essais en boîte blanche .................................................. .................................................. .......................82
JESTANTLNIVEAUX.................................................. .................................................. ..................................83
Tests unitaires ....................................................... .................................................. ..................................83
Tests d'intégration .................................................................. .................................................. .......................83
Test du système .................................................. .................................................. ................................84
Tests d'acceptation .................................................. .................................................. .....................84
Les tests de régression ................................................ .................................................. .......................84
JESTANTDOBSERVATION.................................................. .................................................. ................84
Avant de tester .................................................. .................................................. .............................85
Pendant le test ....................................................................... .................................................. .......................85
Après le test .................................................. .................................................. ................................85
JESTING VS. QUALITÉCCONTRÔLE& UNASSURANCE ETUNUDIT.................................................. .......................86
VUE D'ENSEMBLE DE LA MAINTENANCE DU LOGICIEL .................................. ....................................... 87

JTYPES D'ENTRETIEN.................................................. .................................................. .......................87
COST DEMENTRETIEN.................................................. .................................................. .....................88
iv
Facteurs du monde réel affectant les coûts de maintenance .................................. ................................88
Facteurs finaux du logiciel affectant le coût de maintenance .................................. ................................89
MENTRETIENUNCTIVITÉS.................................................. .................................................. ................89
SLOGICIELRE-INGÉNIERIE.................................................. .................................................. ...............90
Processus de réingénierie .................................................. .................................................. ..................91
Ingénierie inverse .................................................. .................................................. .......................92
Restructuration du programme .................................................. .................................................. ................92
Ingénierie avancée .................................................................. .................................................. ....................92
CRÉUTILISATION DES COMPOSANTS.................................................. .................................................. ....................93
Exemple................................................. .................................................. .......................................93
Processus de réutilisation .................................................. .................................................. ..............................93
VUE D'ENSEMBLE DES OUTILS DU COFFRET LOGICIEL .................................................. .................................................. 100

CAS TOOLS.................................................. .................................................. ..................................100
CCOMPOSANTS DECAS TOOLS.................................................. .................................................. .........100
SFAIRE FACE ÀCASEJOOLS.................................................. .................................................. .......................101
Outils de diagramme .................................................. .................................................. ................................101
Outils de modélisation de processus.................................................. .................................................. ..............101
Outils de gestion de projet .................................................. .................................................. ........102
Outils documentaires .................................................. .................................................. ................102
Outils d'analyse .................................................... .................................................. ................................102
Outils de conception .................................................. .................................................. ..............................102
Outils de gestion de configuration .................................................. ...............................................102
Outils de contrôle des modifications ....................................... .................................................. ..................103
Outils de programmation .................................................. .................................................. ....................103
Outils de prototypage .................................................. .................................................. .......................103
Outils de développement Web ....................................................... .................................................. ............103
Outils d'assurance qualité .................................................. .................................................. .............103
Outils d'entretien .................................................. .................................................. .......................103
v
Présentation du logiciel
1
Comprenons ce que signifie le génie logiciel. Le terme est composé de deux mots, logiciel
et ingénierie.
Logicielest plus qu'un simple code de programme. Un programme est un code exécutable,
qui sert à des fins de calcul. Le logiciel est considéré comme une collection de code de
programmation exécutable, de bibliothèques associées et de documentations. Le logiciel,
lorsqu'il est conçu pour une exigence spécifique, est appeléproduit logiciel.
Ingénieried'autre part, il s'agit de développer des produits, en utilisant des principes et des
méthodes scientifiques bien définis.
Génie logicielest une branche d'ingénierie associée au développement de produits logiciels

utilisant des principes, des méthodes et des procédures scientifiques bien définis. Le
résultat du génie logiciel est un produit logiciel efficace et fiable.
Définitions
L'IEEE définit le génie logiciel comme suit :
1
(1) L'application d'une approche systématique, disciplinée et quantifiable au

développement, à l'exploitation et à la maintenance des logiciels ; c'est-à-dire
l'application de l'ingénierie au logiciel.
(2) L'étude des approches comme dans l'énoncé ci-dessus.
Fritz Bauer, un informaticien allemand, définit le génie logiciel comme :
"L'ingénierie logicielle est l'établissement et l'utilisation de principes d'ingénierie

solides afin d'obtenir économiquement un logiciel fiable et efficace sur de vraies
machines."
Évolution du logiciel
Le processus de développement d'un produit logiciel à l'aide de principes et de méthodes
d'ingénierie logicielle est appeléÉvolution du logiciel.Cela comprend le développement
initial du logiciel, sa maintenance et ses mises à jour, jusqu'à ce que le produit logiciel
souhaité soit développé et réponde aux exigences attendues.
L'évolution commence à partir du processus de collecte des exigences. Après quoi, les
développeurs créent un prototype du logiciel prévu et le montrent aux utilisateurs pour obtenir
leurs commentaires au début du développement du produit logiciel. Les utilisateurs suggèrent
des modifications, sur lesquelles plusieurs mises à jour et maintenance consécutives continuent
également de changer. Ce processus passe au logiciel d'origine, jusqu'à ce que le logiciel
souhaité soit réalisé.
Même une fois que l'utilisateur a le logiciel souhaité en main, l'évolution de la technologie
et l'évolution des exigences obligent le produit logiciel à changer en conséquence. Recréer
un logiciel à partir de zéro et répondre individuellement à l'exigence est
2
pas faisable. La seule solution réalisable et économique consiste à mettre à jour le logiciel
existant afin qu'il corresponde aux dernières exigences.
Lois d'évolution des logiciels

Lehman a donné des lois pour l'évolution des logiciels. Il a divisé le logiciel en trois
catégories différentes :
1.Type statique (type S) -Il s'agit d'un logiciel qui fonctionne strictement selon des
spécifications et solutions. La solution et la méthode pour y parvenir, les deux sont
immédiatement comprises avant le codage. Le logiciel de type s est le moins sujet
aux modifications, c'est donc le plus simple de tous. Par exemple, un programme de
calculatrice pour le calcul mathématique.
2.Type pratique (type P) -Il s'agit d'un logiciel avec une collection deprocédures. Ceci
est défini par exactement ce que les procédures peuvent faire. Dans ce logiciel, les
spécifications peuvent être décrites mais la solution n'est évidemment pas
instantanée. Par exemple, un logiciel de jeu.
3.Type intégré (type E) -Ce logiciel fonctionne étroitement comme l'exigence du monde
réelenvironnement. Ce logiciel a un haut degré d'évolution car il y a divers
changements dans les lois, les taxes, etc. dans les situations du monde réel. Par
exemple, un logiciel de trading en ligne.
Évolution du logiciel E-Type

Lehman a donné huit lois pour l'évolution du logiciel E-Type -
1.Changement continu -Un système logiciel de type E doit continuer à s'adapter aux
changements du monde réel, sinon il devient progressivement moins utile.
2.Complexité croissante -Au fur et à mesure qu'un système logiciel de type E évolue, sa complexité
tend à augmenter à moins que des travaux ne soient effectués pour le maintenir ou le réduire.
3.Conservation de la familiarité -La familiarité avec le logiciel ou la connaissance de la

façon dont il a été développé, pourquoi a-t-il été développé de cette manière
particulière, etc., doit être conservée à tout prix, pour mettre en œuvre les
changements dans le système.
4.Croissance continue-Pour un système de type E destiné à résoudre certains

problèmes commerciaux, sa taille de mise en œuvre des changements augmente en
fonction des changements de mode de vie de l'entreprise.
3
5.Réduction de la qualité -Un système logiciel de type E perd en qualité s'il n'est pas
rigoureusement entretenu et adapté à un environnement opérationnel changeant.
6.Systèmes de rétroaction-Les systèmes logiciels de type E constituent des systèmes de
rétroaction multi-boucles et multi-niveaux et doivent être traités comme tels pour être
modifiés ou améliorés avec succès.
7.Autorégulation -Les processus d'évolution du système de type E s'autorégulent avec

une distribution des mesures produit et processus proche de la normale.
8.Stabilité organisationnelle -Le taux d'activité global effectif moyen dans un
système évolutif de type E est invariant pendant toute la durée de vie du produit.
Paradigmes logiciels
Les paradigmes logiciels font référence aux méthodes et aux étapes suivies lors de la
conception du logiciel. De nombreuses méthodes sont proposées et mises en œuvre. Mais,
nous devons voir où se situent ces paradigmes dans le concept de génie logiciel. Ceux-ci
peuvent être combinés en différentes catégories, bien que chacun d'eux soit contenu l'un
dans l'autre :
Le paradigme de programmation est un sous-ensemble du paradigme de conception logicielle qui est en outre un sous-
ensemble du paradigme de développement logiciel.
Paradigme de développement logiciel

Ce paradigme est connu sous le nom de paradigmes de génie logiciel ; où tous les concepts
d'ingénierie relatifs au développement de logiciels sont appliqués. Il comprend diverses
recherches et collectes d'exigences qui aident le produit logiciel à se construire. Cela
consiste en -
4
- Recueil des besoins

- Conception de logiciels
- La programmation
Paradigme de conception de logiciels

Ce paradigme fait partie du développement logiciel et comprend -
- Conception
- Entretien
- La programmation
Paradigme de programmation
Ce paradigme est étroitement lié à l'aspect programmation du développement logiciel. Ceci
comprend -
- Codage
- Essai
- L'intégration
Besoin de génie logiciel

Le besoin de génie logiciel survient en raison du taux de changement plus élevé des
besoins des utilisateurs et de l'environnement sur lequel le logiciel fonctionne. Voici
quelques-uns des besoins déclarés :
- Gros logiciel -Il est plus facile de construire un mur qu'une maison ou un bâtiment, de même, à
mesure que la taille du logiciel devient grande, l'ingénierie doit prendre des mesures pour lui
donner un processus scientifique.
- Évolutivité-Si le processus logiciel n'était pas basé sur des concepts scientifiques et
techniques, il serait plus facile de recréer un nouveau logiciel que de mettre à l'échelle
un logiciel existant.
- Coût-Comme l'industrie du matériel informatique a montré ses compétences et l'énorme

fabrication a fait baisser le prix du matériel informatique et électronique. Mais, le coût du
logiciel reste élevé si le processus approprié n'est pas adapté.
- Nature dynamique-La nature toujours croissante et adaptative du logiciel dépend

énormément de l'environnement dans lequel l'utilisateur travaille. Si la nature des
logiciels change constamment, de nouvelles améliorations doivent être apportées à
l'existant. C'est là que le génie logiciel joue un bon rôle.
- Gestion de la qualité-Un meilleur processus de développement logiciel fournit un

produit logiciel meilleur et de qualité.
5
Caractéristiques d'un bon logiciel

Un produit logiciel peut être jugé en fonction de ce qu'il offre et de la qualité de son
utilisation. Ce logiciel doit satisfaire pour les motifs suivants :
- Opérationnel
- De transition
- Entretien
Un logiciel bien conçu et conçu doit avoir les caractéristiques suivantes :
Opérationnel
Cela nous indique dans quelle mesure le logiciel fonctionne dans les opérations. Il peut être mesuré sur :
- Budget
- Convivialité
- Efficacité
- Exactitude
- Fonctionnalité
- Fiabilité
- Sécurité
- Sécurité
De transition
Cet aspect est important lorsque le logiciel est déplacé d'une plate-forme à une autre :
- Portabilité
- Interopérabilité
- Réutilisabilité
- Adaptabilité
Entretien
Cet aspect explique dans quelle mesure le logiciel a les capacités de se maintenir dans un
environnement en constante évolution :
- Modularité
- Maintenabilité
- La flexibilité
- Évolutivité
6
En bref, le génie logiciel est une branche de l'informatique, qui utilise des concepts
d'ingénierie bien définis nécessaires pour produire des produits logiciels efficaces,
durables, évolutifs, dans le budget et dans les délais.
7
Cycle de vie du développement logiciel

2
Le cycle de vie du développement logiciel, en abrégé SDLC, est une séquence bien définie et
structurée d'étapes d'ingénierie logicielle pour développer le produit logiciel prévu.
Activités SDLC
SDLC fournit une série d'étapes à suivre pour concevoir et développer efficacement un
produit logiciel. Le cadre SDLC comprend les étapes suivantes :
Communication
Il s'agit de la première étape où l'utilisateur initie la demande d'un produit logiciel souhaité.
L'utilisateur contacte le fournisseur de services et tente de négocier les conditions, soumet
la demande par écrit à l'organisation prestataire de services.
Recueil des exigences

À partir de cette étape, l'équipe de développement du logiciel travaille à la poursuite du
projet. L'équipe discute avec divers intervenants du domaine problématique et essaie de
faire ressortir autant d'informations que possible sur leurs besoins. Les exigences sont
envisagées et séparées en exigences utilisateur, exigences système et exigences
fonctionnelles. Les exigences sont recueillies à l'aide d'un certain nombre de pratiques
comme indiqué -
8
- étudier le système et les logiciels existants ou obsolètes, mener des
- entretiens avec les utilisateurs et les développeurs, se référer à la
- base de données ou
- recueillir les réponses des questionnaires.
Étude de faisabilité
Après la collecte des exigences, l'équipe propose un plan approximatif du processus
logiciel. À cette étape, l'équipe analyse si un logiciel peut être conçu pour répondre à toutes
les exigences de l'utilisateur et s'il existe une possibilité que le logiciel ne soit plus utile. Il
est également analysé si le projet est financièrement, pratiquement et technologiquement
faisable pour l'organisation. Il existe de nombreux algorithmes disponibles, qui aident les
développeurs à conclure la faisabilité d'un projet logiciel.
L'analyse du système
À cette étape, les développeurs décident d'une feuille de route de leur plan et essaient de
proposer le meilleur modèle logiciel adapté au projet. L'analyse du système comprend la
compréhension des limites du produit logiciel, l'apprentissage préalable des problèmes liés au
système ou des modifications à apporter aux systèmes existants, l'identification et la résolution
de l'impact du projet sur l'organisation et le personnel, etc. L'équipe de projet analyse la portée
du projet et planifie le calendrier et ressources en conséquence.
Conception de logiciels
La prochaine étape consiste à apporter toute la connaissance des exigences et de l'analyse sur le bureau et
à concevoir le produit logiciel. Les entrées des utilisateurs et les informations recueillies lors de la phase de
collecte des exigences sont les entrées de cette étape. Le résultat de cette étape se présente sous la forme
de deux conceptions ; conception logique et conception physique. Les ingénieurs produisent des méta-
données et des dictionnaires de données, des diagrammes logiques, des diagrammes de flux de données
et, dans certains cas, des pseudo-codes.
Codage
Cette étape est également appelée phase de programmation. La mise en œuvre de la conception de
logiciels commence par l'écriture de code de programme dans le langage de programmation
approprié et le développement efficace de programmes exécutables sans erreur.
Essai
Une estimation indique que 50% de l'ensemble du processus de développement logiciel devrait être
testé. Les erreurs peuvent ruiner le logiciel du niveau critique à sa propre suppression. Les tests
logiciels sont effectués pendant le codage par les développeurs et des tests approfondis sont
effectués par des experts en test à différents niveaux de code tels que les tests de modules,
9
test de programme, test de produit, test en interne et test du produit chez l'utilisateur. La
découverte précoce des erreurs et leur résolution sont la clé d'un logiciel fiable.
L'intégration
Le logiciel peut devoir être intégré aux bibliothèques, bases de données et autres
programmes. Cette étape de SDLC est impliquée dans l'intégration de logiciels avec des
entités du monde extérieur.
Mise en œuvre
Cela signifie installer le logiciel sur les machines des utilisateurs. Parfois, le logiciel nécessite des
configurations post-installation côté utilisateur. Le logiciel est testé pour la portabilité et
l'adaptabilité et les problèmes liés à l'intégration sont résolus lors de la mise en œuvre.
Opération et maintenance
Cette phase confirme le fonctionnement du logiciel en termes de plus d'efficacité et moins
d'erreurs. Si nécessaire, les utilisateurs sont formés ou aidés avec la documentation sur la façon
d'utiliser le logiciel et comment maintenir le logiciel opérationnel. Le logiciel est maintenu en
temps opportun en mettant à jour le code en fonction des modifications apportées à
l'environnement ou à la technologie de l'utilisateur final. Cette phase peut être confrontée à des
défis liés à des bogues cachés et à des problèmes réels non identifiés.
Paradigme de développement logiciel

Le paradigme de développement logiciel aide un développeur à sélectionner une stratégie pour
développer le logiciel. Un paradigme de développement logiciel a son propre ensemble d'outils, de
méthodes et de procédures, qui sont exprimés clairement et définissent le cycle de vie du
développement logiciel. Quelques paradigmes de développement logiciel ou modèles de processus
sont définis comme suit :
Modèle de cascade
Le modèle en cascade est le modèle le plus simple du paradigme de développement logiciel. Toutes les
phases de SDLC fonctionneront les unes après les autres de manière linéaire. Autrement dit, lorsque la
première phase est terminée, seule la deuxième phase commencera et ainsi de suite.
dix
Ce modèle suppose que tout est réalisé et s'est déroulé parfaitement comme prévu à l'étape
précédente et qu'il n'est pas nécessaire de penser aux problèmes passés qui pourraient survenir
à la phase suivante. Ce modèle ne fonctionne pas correctement s'il reste des problèmes à
l'étape précédente. La nature séquentielle du modèle ne nous permet pas de revenir en arrière
et d'annuler ou de refaire nos actions.
Ce modèle est le mieux adapté lorsque les développeurs ont déjà conçu et développé des
logiciels similaires dans le passé et connaissent tous ses domaines.
Modèle itératif
Ce modèle dirige le processus de développement logiciel par itérations. Il projette le processus
de développement de manière cyclique en répétant chaque étape après chaque cycle du
processus SDLC.
Le logiciel est d'abord développé à très petite échelle et toutes les étapes sont suivies et
prises en considération. Ensuite, à chaque itération suivante, davantage de fonctionnalités
et de modules sont conçus, codés, testés et ajoutés au logiciel. Chaque cycle produit un
logiciel, qui est complet en lui-même et a plus de fonctionnalités et de capacités que celui
du précédent.
Après chaque itération, l'équipe de direction peut travailler sur la gestion des risques et
préparer la prochaine itération. Parce qu'un cycle comprend une petite partie de l'ensemble
11
processus logiciel, il est plus facile de gérer le processus de développement mais il consomme plus
de ressources.
Modèle en spirale
Le modèle en spirale est une combinaison du modèle itératif et du modèle SDLC. Cela peut être
considéré comme si vous choisissiez un modèle SDLC et que vous le combiniez avec un processus
cyclique (modèle itératif).
Ce modèle tient compte du risque, qui passe souvent inaperçu par la plupart des autres
modèles. Le modèle commence par déterminer les objectifs et les contraintes du logiciel au
début d'une itération. La phase suivante consiste à prototyper le logiciel. Cela inclut l'analyse des
risques. Ensuite, un modèle SDLC standard est utilisé pour créer le logiciel. Dans la quatrième
phase du plan de la prochaine itération est préparé.
V-modèle
L'inconvénient majeur du modèle en cascade est que nous ne passons à l'étape suivante que lorsque la
précédente est terminée et qu'il n'y avait aucune chance de revenir en arrière si quelque chose est
12
trouvée erronée dans les étapes ultérieures. V-Model fournit des moyens de tester le logiciel à
chaque étape de manière inverse.
À chaque étape, des plans de test et des cas de test sont créés pour vérifier et valider le
produit en fonction des exigences de cette étape. Par exemple, dans la phase de collecte
des exigences, l'équipe de test prépare tous les cas de test en correspondance avec les
exigences. Plus tard, lorsque le produit est développé et prêt à être testé, les cas de test de
cette étape vérifient la validité du logiciel par rapport aux exigences de cette étape.
Cela rend la vérification et la validation en parallèle. Ce modèle est également appelé

modèle de vérification et de validation.
13
Modèle Big Bang

Ce modèle est le modèle le plus simple dans sa forme. Cela nécessite peu de planification, beaucoup
de programmation et beaucoup de fonds. Ce modèle est conceptualisé autour du big bang de
l'univers. Comme le disent les scientifiques, après le big bang, de nombreuses galaxies, planètes et
étoiles ont évolué comme un événement. De même, si nous rassemblons beaucoup de
programmation et de fonds, vous pouvez obtenir le meilleur produit logiciel.
Pour ce modèle, très peu de planification est nécessaire. Il ne suit aucun processus, ou
parfois le client n'est pas sûr des exigences et des besoins futurs. Les exigences d'entrée
sont donc arbitraires.
Ce modèle n'est pas adapté aux grands projets logiciels mais bon pour l'apprentissage et
l'expérimentation.
14
Gestion de projet logiciel

3
Le modèle de travail d'une entreprise informatique engagée dans le développement de logiciels peut être divisé
en deux parties :
- Création de logiciels
- Gestion de projet logiciel
Un projet est une tâche bien définie, qui est un ensemble de plusieurs opérations effectuées dans le
but d'atteindre un objectif (par exemple, le développement et la livraison de logiciels). Un Projet peut
être caractérisé comme :
- Chaque projet peut avoir un objectif unique et distinct. Le projet n'est pas
- une activité de routine ou une opération quotidienne. Le projet est livré
- avec une heure de début et de fin.
- Le projet se termine lorsque son objectif est atteint. Il s'agit donc d'une phase
temporaire dans la vie d'une organisation.
- Le projet a besoin de ressources adéquates en termes de temps, de main-d'œuvre, de financement, de

matériel et de banque de connaissances.
Projet logiciel
Un projet logiciel est la procédure complète de développement logiciel, de la collecte des
exigences aux tests et à la maintenance, réalisée conformément aux méthodologies
d'exécution, dans une période de temps spécifiée pour obtenir le produit logiciel prévu.
Besoin de gestion de projet logiciel

Le logiciel est dit être un produit immatériel. Le développement de logiciels est une sorte de tout
nouveau courant dans les affaires mondiales et il y a très peu d'expérience dans la construction
de produits logiciels. La plupart des produits logiciels sont conçus sur mesure pour répondre
aux besoins des clients. Le plus important est que la technologie sous-jacente change et
progresse si fréquemment et si rapidement que l'expérience d'un produit peut ne pas être
appliquée à l'autre. Toutes ces contraintes commerciales et environnementales
15
risque dans le développement logiciel, il est donc essentiel de gérer efficacement les projets
logiciels.
L'image ci-dessus montre les triples contraintes pour les projets logiciels. C'est un élément
essentiel de l'organisation logicielle pour fournir un produit de qualité, en maintenant le coût
dans les limites du budget du client et en livrant le projet comme prévu. Plusieurs facteurs,
internes et externes, peuvent avoir un impact sur ce triangle à triple contrainte. Chacun de ces
trois facteurs peut avoir un impact important sur les deux autres.
Par conséquent, la gestion de projet logiciel est essentielle pour intégrer les besoins des
utilisateurs ainsi que les contraintes de budget et de temps.
Chef de projet logiciel

Un chef de projet logiciel est une personne qui assume la responsabilité de l'exécution du
projet logiciel. Le chef de projet logiciel connaît parfaitement toutes les phases du SDLC que
le logiciel traverserait. Le chef de projet peut ne jamais s'impliquer directement dans la
production du produit final, mais il contrôle et gère les activités impliquées dans la
production.
Un chef de projet surveille de près le processus de développement, prépare et exécute

divers plans, organise les ressources nécessaires et adéquates, maintient la communication
entre tous les membres de l'équipe afin de résoudre les problèmes de coût, de budget, de
ressources, de temps, de qualité et de satisfaction client.
Voyons quelques responsabilités qu'un chef de projet assume -
Gérer des gens

- Agir en tant que chef de projet Lésion avec les
- parties prenantes Gestion des ressources
- humaines Mise en place de la hiérarchie
- hiérarchique etc.
16
Gestion de projet
- Définition et mise en place de la portée du projet
- Gestion des activités de gestion de projet Suivi des
- progrès et des performances Analyse des risques
- à chaque phase
- Prendre les mesures nécessaires pour éviter ou sortir des problèmes Agir
- en tant que porte-parole du projet
Activités de gestion de logiciels

La gestion de projet logiciel comprend un certain nombre d'activités, qui comprennent la
planification du projet, la définition de la portée du produit logiciel, l'estimation des coûts en
divers termes, la planification des tâches et des événements et la gestion des ressources. Les
activités de gestion de projet peuvent inclure :
- Planification de projet
- Gestion de la portée
- Estimation du projet
Planification de projet
La planification du projet logiciel est une tâche qui est effectuée avant le démarrage effectif de
la production du logiciel. Il est là pour la production de logiciels mais n'implique aucune activité
concrète ayant un lien direct avec la production de logiciels ; il s'agit plutôt d'un ensemble de
processus multiples, ce qui facilite la production de logiciels. La planification du projet peut
inclure les éléments suivants :
Gestion de la portée
Il définit la portée du projet ; cela inclut toutes les activités, le processus doit être fait pour
créer un produit logiciel livrable. La gestion de la portée est essentielle car elle crée les
limites du projet en définissant clairement ce qui serait fait dans le projet et ce qui ne serait
pas fait. Cela permet au projet de contenir des tâches limitées et quantifiables, qui peuvent
facilement être documentées et évitent ainsi les dépassements de coûts et de temps.
Lors de la gestion du périmètre du projet, il est nécessaire de -
- Définir le périmètre
- Décider de sa vérification et de son contrôle
- Divisez le projet en plusieurs parties plus petites pour en faciliter la gestion.
17
- Vérifier la portée
- Contrôler le périmètre en incorporant des modifications au périmètre
Estimation du projet
Pour une gestion efficace, une estimation précise des différentes mesures est indispensable.
Avec une estimation correcte, les responsables peuvent gérer et contrôler le projet de manière
plus efficace et efficiente.
L'estimation du projet peut impliquer les éléments suivants :
- Estimation de la taille du logiciel
La taille du logiciel peut être estimée soit en termes de KLOC (Kilo Line of Code) soit en
calculant le nombre de points de fonction dans le logiciel. Les lignes de code dépendent
des pratiques de codage. Les points de fonction varient selon l'exigence de l'utilisateur
ou du logiciel.
- Estimation de l'effort
Le responsable évalue les efforts en termes de besoins en personnel et d'heures de

travail nécessaires pour produire le logiciel. Pour l'estimation de l'effort, la taille du
logiciel doit être connue. Cela peut être dérivé de l'expérience du gestionnaire, des
données historiques de l'organisation ou la taille du logiciel peut être convertie en
efforts en utilisant des formules standard.
- Estimation du temps
Une fois la taille et les efforts estimés, le temps nécessaire pour produire le logiciel
peut être estimé. Les efforts requis sont séparés en sous-catégories selon les
spécifications des exigences et l'interdépendance des divers composants du
logiciel. Les tâches logicielles sont divisées en tâches, activités ou événements plus
petits par Work Breakthrough Structure (WBS). Les tâches sont planifiées au jour le
jour ou en mois calendaires.
La somme du temps nécessaire pour accomplir toutes les tâches en heures ou en jours correspond au
temps total investi pour mener à bien le projet.
- Estimation du coût
18
Cela pourrait être considéré comme le plus difficile de tous car il dépend de plus d'éléments
que n'importe lequel des précédents. Pour estimer le coût du projet, il est nécessaire de
prendre en compte -
- Taille du logiciel
- Qualité du logiciel
- Matériel
- Logiciels ou outils supplémentaires, licences, etc. Personnel
- qualifié ayant des compétences spécifiques à la tâche
- Déplacements impliqués
- Communication
- Formation et accompagnement
Techniques d'estimation de projet

Nous avons discuté de divers paramètres impliquant l'estimation du projet tels que la taille, l'effort, le
temps et le coût.
Le chef de projet peut estimer les facteurs énumérés à l'aide de deux techniques largement
reconnues -
Technique de décomposition
Cette technique considère le logiciel comme un produit de diverses compositions.
Il existe deux modèles principaux -
- Ligne de code :Ici, l'estimation est faite pour le compte du nombre de lignes de

codes dans le produit logiciel.
- Points de fonction :Ici, l'estimation est effectuée pour le compte du nombre de

points de fonction dans le produit logiciel.
Technique d'estimation empirique

Cette technique utilise des formules dérivées de manière empirique pour effectuer une estimation. Ces
formules sont basées sur le LOC ou les FP.
-Modèle Putnam
Ce modèle est fait par Lawrence H. Putnam, qui est basé sur la distribution de fréquence
de Norden (courbe de Rayleigh). Le modèle Putnam cartographie le temps et les efforts
requis avec la taille du logiciel.
- COCOMO
19
COCOMO signifie Constructive Cost Model, développé par Barry W. Boehm. Il divise
le produit logiciel en trois catégories de logiciels : organiques, semi-détachés et
embarqués.
Planification du projet
La planification de projet dans un projet fait référence à la feuille de route de toutes les activités
à effectuer dans un ordre spécifié et dans les délais impartis à chaque activité. Les chefs de
projet ont tendance à définir diverses tâches et jalons de projet, puis à les organiser en tenant
compte de divers facteurs. Ils recherchent des tâches comme dans le chemin critique dans le
calendrier, qui doivent être complétées de manière spécifique (en raison de l'interdépendance
des tâches) et strictement dans le temps imparti. La disposition des tâches qui se trouve hors du
chemin critique est moins susceptible d'avoir un impact sur tout le calendrier du projet.
Pour programmer un projet, il est nécessaire de -
- Décomposer les tâches du projet en une forme plus petite et

- gérable Découvrir diverses tâches et les corréler
- Estimer le temps requis pour chaque tâche Diviser
- le temps en unités de travail
- Attribuer un nombre adéquat d'unités de travail pour chaque tâche
- Calculer le temps total requis pour le projet du début à la fin
La gestion des ressources

Tous les éléments utilisés pour développer un produit logiciel peuvent être considérés comme des ressources
pour ce projet. Cela peut inclure les ressources humaines, les outils de production et les bibliothèques de
logiciels.
Les ressources sont disponibles en quantité limitée et restent dans l'organisation en tant que pool
d'actifs. Le manque de ressources entrave le développement du projet et celui-ci peut prendre du
retard sur le calendrier. L'allocation de ressources supplémentaires augmente les coûts de
développement en fin de compte. Il est donc nécessaire d'estimer et d'allouer des ressources
adéquates pour le projet.
La gestion des ressources comprend -
- Définir le bon projet d'organisation en créant une équipe de projet et en attribuant

des responsabilités à chaque membre de l'équipe
- Déterminer les ressources nécessaires à une étape particulière et leur disponibilité
20
- Gérez les ressources en générant une demande de ressources lorsqu'elles sont

nécessaires et en les désallouant lorsqu'elles ne sont plus nécessaires.
Gestion des risques du projet

La gestion des risques implique toutes les activités relatives à l'identification, l'analyse et la
provision des risques prévisibles et non prévisibles dans le projet. Le risque peut inclure ce
qui suit :
- Personnel expérimenté quittant le projet et nouveau personnel entrant.
- Changement dans la gestion organisationnelle.
- Modification de l'exigence ou mauvaise interprétation de l'exigence.
- Sous-estimation du temps et des ressources nécessaires.
- Changements technologiques, changements environnementaux, concurrence commerciale.
Processus de gestion des risques

Les activités suivantes sont impliquées dans le processus de gestion des risques :
- Identification -Prenez note de tous les risques possibles qui peuvent survenir dans le cadre du
projet.
- Catégoriser -Classez les risques connus en intensité de risque élevée, moyenne et

faible selon leur impact possible sur le projet.
- Gérer -Analyser la probabilité d'occurrence des risques à différentes phases. Faites un plan
pour éviter ou faire face aux risques. Essayez de minimiser leurs effets secondaires.
- Moniteur -Surveillez de près les risques potentiels et leurs premiers symptômes. Surveillez
également les mesures efficaces prises pour les atténuer ou les éviter.
Exécution et suivi du projet

Dans cette phase, les tâches décrites dans les plans de projet sont exécutées selon leurs
échéanciers.
L'exécution doit être surveillée afin de vérifier si tout se déroule conformément au plan. La
surveillance consiste à observer pour vérifier la probabilité d'un risque et à prendre des
mesures pour faire face au risque ou signaler l'état de diverses tâches.
Ces mesures comprennent -
21
- Suivi d'activité -Toutes les activités planifiées dans une tâche peuvent être
surveillées au jour le jour. Lorsque toutes les activités d'une tâche sont terminées,
elle est considérée comme terminée.
- Rapports d'état -Les rapports contiennent l'état des activités et des tâches réalisées
dans un délai donné, généralement une semaine. Le statut peut être marqué
comme terminé, en attente ou en cours, etc.
- Liste de vérification des jalons -Chaque projet est divisé en plusieurs phases où les
principales tâches sont exécutées (jalons) en fonction des phases du SDLC. Cette liste de
contrôle des jalons est préparée toutes les quelques semaines et rapporte l'état des
jalons.
Gestion des communications du projet

Une communication efficace joue un rôle essentiel dans la réussite d'un projet. Il comble les
écarts entre le client et l'organisation, entre les membres de l'équipe ainsi que les autres
parties prenantes du projet telles que les fournisseurs de matériel.
La communication peut être orale ou écrite. Le processus de gestion de la communication peut

comporter les étapes suivantes :
- Planification-Cette étape comprend l'identification de tous les acteurs du projet et

le mode de communication entre eux. Il examine également si des installations de
communication supplémentaires sont nécessaires.
- Partage-Après avoir déterminé divers aspects de la planification, le responsable se concentre sur

le partage des informations correctes avec la bonne personne au bon moment. Cela permet à
toutes les personnes impliquées dans le projet de se tenir au courant de l'avancement du projet et
de son statut.
- Retour-Les chefs de projet utilisent diverses mesures et mécanismes de rétroaction

et créent des rapports d'état et de performance. Ce mécanisme garantit que les
contributions des différentes parties prenantes parviennent au chef de projet sous
forme de commentaires.
- Fermeture-À la fin de chaque événement majeur, à la fin d'une phase de SDLC ou à la fin du projet
lui-même, une clôture administrative est officiellement annoncée pour informer chaque partie
prenante en envoyant un courrier électronique, en distribuant une copie papier du document ou
par tout autre moyen de communication efficace.
Après la clôture, l'équipe passe à la phase ou au projet suivant.
22
Gestion de la configuration
La gestion de la configuration est un processus de suivi et de contrôle des modifications
apportées au logiciel en termes d'exigences, de conception, de fonctions et de développement
du produit.
L'IEEE le définit comme "le processus d'identification et de définition des éléments du système, de contrôle
du changement de ces éléments tout au long de leur cycle de vie, d'enregistrement et de rapport de l'état
des éléments et des demandes de modification, et de vérification de l'exhaustivité et de l'exactitude des
éléments".
Généralement, une fois que le SRS est finalisé, il y a moins de chances que l'utilisateur demande des
modifications. S'ils se produisent, les changements ne sont traités qu'avec l'approbation préalable de la
haute direction, car il existe une possibilité de dépassement des coûts et des délais.
Ligne de base
Une phase de SDLC est supposée terminée si elle est basée sur la ligne de base, c'est-à-dire que la ligne de
base est une mesure qui définit l'intégralité d'une phase. Une phase est initialisée lorsque toutes les
activités qui s'y rapportent sont terminées et bien documentées. Si ce n'était pas la phase finale, sa sortie
serait utilisée dans la prochaine phase immédiate.
La gestion de la configuration est une discipline de l'administration de l'organisation, qui

s'occupe de l'occurrence de tout changement (processus, exigence, technologique, stratégique,
etc.) après qu'une phase a été établie. CM surveille toutes les modifications apportées au
logiciel.
Le contrôle des changements
Le contrôle des modifications est une fonction de la gestion de la configuration, qui garantit que toutes les
modifications apportées au système logiciel sont cohérentes et conformes aux règles et réglementations
organisationnelles.
Un changement dans la configuration du produit passe par les étapes suivantes -
- Identification-Une demande de modification provient d'une source interne ou externe.

Lorsque la demande de changement est formellement identifiée, elle est correctement
documentée.
- Validation-La validité de la demande de changement est vérifiée et sa procédure de

traitement est confirmée.
- Analyse-L'impact de la demande de changement est analysé en termes de

calendrier, de coût et d'efforts requis. L'impact global du changement prospectif sur
le système est analysé.
23
- Contrôle-Si le changement éventuel affecte trop d'entités dans le système ou s'il est
inévitable, il est obligatoire d'obtenir l'approbation des hautes autorités avant que le
changement ne soit intégré au système. Il est décidé si le changement vaut la peine
d'être incorporé ou non. Si ce n'est pas le cas, la demande de modification est
formellement refusée.
- Exécution-Si la phase précédente décide d'exécuter la demande de changement,

cette phase prend les mesures appropriées pour exécuter le changement, par le
biais d'une révision approfondie si nécessaire.
- Fermer la demande-Le changement est vérifié pour une mise en œuvre correcte et une
fusion avec le reste du système. Ce changement nouvellement incorporé dans le logiciel
est correctement documenté et la demande est officiellement fermée.
Outils de gestion de projet

Le risque et l'incertitude sont multipliés par rapport à la taille du projet, même lorsque le
projet est développé selon des méthodologies définies.
Il existe des outils disponibles qui aident à une gestion de projet efficace. Quelques-uns
sont décrits : -
Diagramme de Gantt
Le diagramme de Gantt a été conçu par Henry Gantt (1917). Il représente le calendrier du projet par
rapport aux périodes de temps. Il s'agit d'un graphique à barres horizontales avec des barres représentant
les activités et le temps prévu pour les activités du projet.
24
Graphique PERT
Le diagramme PERT (Program Evaluation & Review Technique) est un outil qui représente le projet sous
forme de diagramme de réseau. Il est capable de représenter graphiquement les principaux événements
du projet de manière parallèle et consécutive. Les événements, qui se produisent les uns après les autres,
montrent la dépendance du dernier événement par rapport au précédent.
Les événements sont affichés sous forme de nœuds numérotés. Ils sont reliés par des flèches
étiquetées décrivant la séquence des tâches dans le projet.
Histogramme des ressources

Il s'agit d'un outil graphique qui contient une barre ou un graphique représentant le nombre de ressources
(généralement du personnel qualifié) nécessaires au fil du temps pour un événement (ou une phase) du projet.
Resource Histogram est un outil efficace pour la planification et la coordination du personnel.
25
Analyse du chemin critique

Cet outil est utile pour reconnaître les tâches interdépendantes dans le projet. Cela aide également à
trouver le chemin le plus court ou le chemin critique pour mener à bien le projet. Comme le
diagramme PERT, chaque événement se voit attribuer un laps de temps spécifique. Cet outil montre
la dépendance de l'événement en supposant qu'un événement ne peut passer au suivant que si le
précédent est terminé.
Les événements sont organisés en fonction de leur heure de début la plus précoce possible. Le chemin entre le
nœud de début et le nœud de fin est un chemin critique qui ne peut pas être réduit davantage et tous les
événements doivent être exécutés dans le même ordre.
26
Logiciels requis
4
Les exigences logicielles sont la description des caractéristiques et des fonctionnalités du
système cible. Les exigences traduisent les attentes des utilisateurs vis-à-vis du produit
logiciel. Les exigences peuvent être évidentes ou cachées, connues ou inconnues,
attendues ou inattendues du point de vue du client.
Ingénierie des exigences

Le processus pour rassembler les exigences logicielles du client, les analyser et les
documenter est connu sous le nom d'ingénierie des exigences.
L'objectif de l'ingénierie des exigences est de développer et de maintenir un document

sophistiqué et descriptif de «spécification des exigences du système».
Processus d'ingénierie des exigences

Il s'agit d'un processus en quatre étapes, qui comprend -
- Étude de faisabilité
- Recueil des exigences

- Spécification des exigences logicielles
- Validation des exigences logicielles
Voyons brièvement le processus -
Étude de faisabilité
Lorsque le client approche l'organisation pour faire développer le produit souhaité, il a une
idée approximative de toutes les fonctions que le logiciel doit exécuter et de toutes les
fonctionnalités attendues du logiciel.
En se référant à ces informations, les analystes effectuent une étude détaillée pour déterminer si le
système souhaité et ses fonctionnalités sont réalisables à développer.
Cette étude de faisabilité est axée sur l'objectif de l'organisation. Cette étude analyse si le
produit logiciel peut être matérialisé de manière pratique en termes de mise en œuvre, de
contribution du projet à l'organisation, de contraintes de coûts, et selon les valeurs et les
objectifs de l'organisation. Il explore les aspects techniques de la
91
projet et produit tels que l'utilisabilité, la maintenabilité, la productivité et la capacité

d'intégration.
Le résultat de cette phase devrait être un rapport d'étude de faisabilité qui devrait contenir
des commentaires et des recommandations adéquats pour la direction quant à savoir si le
projet doit être entrepris ou non.
Recueil des exigences

Si le rapport de faisabilité est positif pour entreprendre le projet, la phase suivante
commence par la collecte des exigences de l'utilisateur. Les analystes et les ingénieurs
communiquent avec le client et les utilisateurs finaux pour connaître leurs idées sur ce que
le logiciel doit fournir et sur les fonctionnalités qu'ils souhaitent inclure dans le logiciel.
Spécification des exigences logicielles (SRS)

Le SRS est un document créé par l'analyste système après que les exigences ont été collectées auprès des
différentes parties prenantes.
SRS définit comment le logiciel prévu interagira avec le matériel, les interfaces externes, la
vitesse de fonctionnement, le temps de réponse du système, la portabilité du logiciel sur
diverses plates-formes, la maintenabilité, la vitesse de récupération après un crash, la sécurité,
la qualité, les limitations, etc.
Les exigences reçues du client sont écrites en langage naturel. Il est de la responsabilité de
l'analyste système de documenter les exigences dans un langage technique afin qu'elles
puissent être comprises et utilisées par l'équipe de développement logiciel.
SRS devrait proposer les fonctionnalités suivantes :
- Les besoins des utilisateurs sont exprimés en langage naturel.
- Les exigences techniques sont exprimées dans un langage structuré, qui est utilisé au
sein de l'organisation.
- La description de la conception doit être écrite en pseudo-code.
- Format des formulaires et des sérigraphies de l'interface graphique.
- Notations conditionnelles et mathématiques pour les DFD, etc.
Validation des exigences logicielles

Une fois les spécifications des exigences élaborées, les exigences mentionnées dans ce document
sont validées. L'utilisateur peut demander une solution illégale et peu pratique ou les experts
peuvent interpréter les exigences de manière inexacte. Cela se traduit par une énorme augmentation
28
en coût s'il n'est pas étouffé dans l'œuf. Les exigences peuvent être vérifiées par rapport aux conditions
suivantes -
- S'ils peuvent être pratiquement mis en œuvre
- S'ils sont valides et selon la fonctionnalité et le domaine du logiciel S'il y a

- des ambiguïtés
- S'ils sont complets
- S'ils peuvent être démontrés
Processus d'élicitation des exigences

Le processus d'élicitation des exigences peut être décrit à l'aide du diagramme suivant :
- Rassemblement des exigences -Les développeurs discutent avec le client et les utilisateurs
finaux et connaissent leurs attentes vis-à-vis du logiciel.
- Exigences d'organisation -Les développeurs hiérarchisent et organisent les

exigences par ordre d'importance, d'urgence et de commodité.
- Négociation & discussion -Si les exigences sont ambiguës ou s'il y a des conflits
dans les exigences des différentes parties prenantes, cela est alors négocié et
discuté avec les parties prenantes. Les exigences peuvent alors être hiérarchisées et
raisonnablement compromises.
Les exigences émanent de diverses parties prenantes. Pour lever l'ambiguïté et les
conflits, ils sont discutés pour plus de clarté et d'exactitude. Les exigences irréalistes
sont raisonnablement compromises.
- Documentation -Toutes les exigences formelles et informelles, fonctionnelles et non

fonctionnelles sont documentées et mises à disposition pour le traitement de la phase
suivante.
Techniques d'élicitation des exigences

L'élicitation des exigences est le processus permettant de déterminer les exigences d'un système
logiciel prévu en communiquant avec le client, les utilisateurs finaux, les utilisateurs du système et les
autres personnes concernées par le développement du système logiciel.
Il existe différentes façons de découvrir les exigences. Certains d'entre eux sont expliqués ci-
dessous :
29
Entrevues
Les entretiens sont un moyen solide pour recueillir les exigences. L'organisation peut mener
plusieurs types d'entretiens tels que :
- Des entretiens structurés (fermés), où chaque information à recueillir est décidée à

l'avance, ils suivent fermement le modèle et le sujet de discussion.
- Entretiens non structurés (ouverts), où les informations à recueillir ne sont pas

décidées à l'avance, plus flexibles et moins biaisées.
- Entretiens oraux
- Entretiens écrits
- Entretiens individuels qui se déroulent entre deux personnes de l'autre côté de la

table.
- Entrevues de groupe qui ont lieu entre des groupes de participants. Ils aident à
découvrir toute exigence manquante car de nombreuses personnes sont impliquées.
Enquêtes
L'organisation peut mener des enquêtes auprès de diverses parties prenantes en les
interrogeant sur leurs attentes et leurs exigences vis-à-vis du système à venir.
Questionnaires
Un document avec un ensemble prédéfini de questions objectives et d'options respectives est
remis à toutes les parties prenantes pour réponse, qui sont collectées et compilées.
Une lacune de cette technique est que si une option pour un problème n'est pas mentionnée dans le
questionnaire, le problème peut être laissé sans surveillance.
Analyse des tâches

Une équipe d'ingénieurs et de développeurs peut analyser l'opération pour laquelle le
nouveau système est requis. Si le client dispose déjà d'un logiciel pour effectuer certaines
opérations, il est étudié et les exigences du système proposé sont collectées.
Analyse de domaine
Chaque logiciel appartient à une catégorie de domaine. Les personnes expertes dans le domaine peuvent
être d'une grande aide pour analyser les exigences générales et spécifiques.
Réflexion
Un débat informel a lieu entre les différentes parties prenantes et toutes leurs contributions sont
enregistrées pour une analyse plus approfondie des besoins.
30
Prototypage
Le prototypage consiste à créer une interface utilisateur sans ajouter de fonctionnalités détaillées
permettant à l'utilisateur d'interpréter les fonctionnalités du produit logiciel prévu. Cela aide à
donner une meilleure idée des besoins. S'il n'y a pas de logiciel installé chez le client pour la référence
du développeur et que le client n'est pas conscient de ses propres exigences, le développeur crée un
prototype basé sur les exigences initialement mentionnées. Le prototype est montré au client et les
commentaires sont notés. Les commentaires des clients servent d'entrée pour la collecte des
exigences.
Observation
Une équipe d'experts visite l'organisation ou le lieu de travail du client. Ils observent le
fonctionnement réel des systèmes installés existants. Ils observent le flux de travail chez le
client et comment les problèmes d'exécution sont traités. L'équipe elle-même tire quelques
conclusions qui aident à formuler les exigences attendues du logiciel.
Caractéristiques des exigences logicielles

La collecte des exigences logicielles est à la base de l'ensemble du projet de développement
logiciel. Elles doivent donc être claires, correctes et bien définies.
Une spécification complète des exigences logicielles doit être :
- Clair
- Correct
- Cohérent
- Cohérent
- Compréhensible
- Modifiable
- Vérifiable
- Prioritaire
- Non ambigu
- Traçable
- Source crédible
Logiciels requis
Nous devrions essayer de comprendre quel type d'exigences peuvent survenir dans la
phase d'élicitation des exigences et quels types d'exigences sont attendus du système
logiciel.
31
De manière générale, les exigences logicielles doivent être classées en deux catégories :
Exigences fonctionnelles
Les exigences liées à l'aspect fonctionnel du logiciel entrent dans cette catégorie.
Ils définissent les fonctions et les fonctionnalités dans et depuis le système logiciel.
EXEMPLES -
- Option de recherche donnée à l'utilisateur pour effectuer une recherche à partir de diverses factures.
- L'utilisateur doit être en mesure d'envoyer n'importe quel rapport à la direction.
- Les utilisateurs peuvent être divisés en groupes et les groupes peuvent recevoir des droits distincts.
- Devrait se conformer aux règles commerciales et aux fonctions administratives.
- Le logiciel est développé en gardant la compatibilité descendante intacte.
Prérogatives non fonctionnelles

Les exigences, qui ne sont pas liées à l'aspect fonctionnel du logiciel, entrent dans cette
catégorie. Ce sont des caractéristiques implicites ou attendues du logiciel, que les
utilisateurs supposent.
Les exigences non fonctionnelles comprennent -
- Sécurité
- Enregistrement
- Stockage
- Configuration
- Performance
- Coût
- Interopérabilité
- La flexibilité
- Reprise après sinistre
- Accessibilité
Les exigences sont classées logiquement comme :
- Doit avoir:Le logiciel ne peut pas être dit opérationnel sans eux.
- Avoir dû:Amélioration des fonctionnalités du logiciel.
- Pourrais avoir:Le logiciel peut toujours fonctionner correctement avec ces exigences.
- Liste de souhaits:Ces exigences ne correspondent à aucun objectif du logiciel.
32
Lors du développement d'un logiciel, le "must have" doit être mis en œuvre, le "devrait avoir" est un sujet de
débat avec les parties prenantes et de négation, tandis que le "pourrait avoir" et la "liste de souhaits" peuvent
être conservés pour les mises à jour logicielles.
Exigences de l'interface utilisateur

L'interface utilisateur (UI) est une partie importante de tout logiciel, matériel ou système
hybride. Un logiciel est largement accepté s'il est -
- facile à utiliser
- réponse rapide
- gérer efficacement les erreurs opérationnelles en fournissant
- une interface utilisateur simple mais cohérente
L'acceptation par l'utilisateur dépend principalement de la façon dont l'utilisateur peut utiliser le
logiciel. L'interface utilisateur est le seul moyen pour les utilisateurs de percevoir le système. Un
système logiciel performant doit également être équipé d'une interface utilisateur attrayante, claire,
cohérente et réactive. Sinon, les fonctionnalités du système logiciel ne peuvent pas être utilisées de
manière pratique. Un système est dit bon s'il fournit les moyens de l'utiliser efficacement. Les
exigences de l'interface utilisateur sont brièvement mentionnées ci-dessous -
- Présentation du contenu
- Navigation facile
- Interface simplifiée
- Sensible
- Éléments d'interface utilisateur cohérents
- Mécanisme de rétroaction
- Paramètres par défaut
- Mise en page utile

- Utilisation stratégique de la couleur et de la texture.
- Fournir des informations d'aide
- Approche centrée sur l'utilisateur
- Paramètres d'affichage basés sur le groupe.
Analyste système logiciel

L'analyste de système dans une organisation informatique est une personne qui analyse les
exigences du système proposé et s'assure que les exigences sont conçues et documentées
correctement et avec précision. Le rôle d'un analyste commence pendant la phase d'analyse logicielle
33
de SDLC. Il est de la responsabilité de l'analyste de s'assurer que le logiciel développé

répond aux exigences du client.
Les analystes système ont les responsabilités suivantes :
- Analyser et comprendre les exigences du logiciel prévu
- Comprendre comment le projet contribuera aux objectifs organisationnels
- Identifier les sources d'exigence
- Validation de l'exigence
- Élaborer et mettre en œuvre un plan de gestion des exigences
- Documentation des exigences commerciales, techniques, de processus et de produit
- Coordination avec les clients pour hiérarchiser les exigences et lever l'ambiguïté
- Finalisation des critères d'acceptation avec le client et les autres parties prenantes
Métriques et mesures logicielles

Les mesures logicielles peuvent être comprises comme un processus de quantification et de
symbolisation de divers attributs et aspects du logiciel.
Software Metrics fournit des mesures pour divers aspects du processus logiciel et du
produit logiciel.
Les mesures logicielles sont des exigences fondamentales du génie logiciel. Ils aident non
seulement à contrôler le processus de développement logiciel, mais également à maintenir
l'excellente qualité du produit final.
Selon Tom DeMarco, un (ingénieur logiciel), "Vous ne pouvez pas contrôler ce que vous ne pouvez
pas mesurer." Par ses propos, il est très clair à quel point les mesures logicielles sont importantes.
Voyons quelques métriques logicielles :
- Métriques de taille -Lignes de code (LOC) (), principalement calculées en milliers de

lignes de code source fournies, notées KLOC.
- Le nombre de points de fonction est la mesure de la fonctionnalité fournie par le

logiciel. Le nombre de points de fonction définit la taille de l'aspect fonctionnel du
logiciel.
- Métriques de complexité -La complexité cyclomatique de McCabe quantifie la

borne supérieure du nombre de chemins indépendants dans un programme, qui est
34
perçue comme la complexité du programme ou de ses modules. Il est représenté en termes de

concepts de théorie des graphes en utilisant un graphe de flux de contrôle.
- Indicateurs de qualité -Les défauts, leurs types et causes, leurs conséquences,

l'intensité de leur gravité et leurs implications définissent la qualité du produit.
- Le nombre de défauts trouvés dans le processus de développement et le nombre de

défauts signalés par le client après l'installation ou la livraison du produit chez le client
définissent la qualité du produit.
- Métriques de processus -Dans les différentes phases de SDLC, les méthodes et outils
utilisés, les normes de l'entreprise et la performance du développement sont des métriques
de processus logiciels.
- Métriques des ressources -L'effort, le temps et les diverses ressources utilisées représentent des
métriques pour la mesure des ressources.
35
Principes de base de la conception de logiciels

5
La conception de logiciels est un processus visant à transformer les exigences des utilisateurs en une
forme appropriée, ce qui aide le programmeur dans le codage et la mise en œuvre du logiciel.
Pour évaluer les besoins des utilisateurs, un document SRS (Software Requirement Specification)
est créé alors que pour le codage et la mise en œuvre, il est nécessaire d'avoir des exigences
plus spécifiques et détaillées en termes de logiciel. La sortie de ce processus peut être
directement utilisée dans l'implémentation dans les langages de programmation.
La conception de logiciels est la première étape du SDLC (Software Design Life Cycle), qui
déplace la concentration du domaine du problème au domaine de la solution. Il essaie de
spécifier comment remplir les exigences mentionnées dans SRS.
Niveaux de conception du logiciel

La conception du logiciel produit trois niveaux de résultats :
- Conception architecturale -La conception architecturale est la version abstraite la plus

élevée du système. Il identifie le logiciel comme un système avec de nombreux
composants interagissant les uns avec les autres. A ce niveau, les concepteurs se font
une idée du domaine de solution proposé.
- Conception de haut niveau -La conception de haut niveau brise le concept de

conception architecturale « entité unique à composants multiples » en une vue
moins abstraite des sous-systèmes et des modules et décrit leur interaction les uns
avec les autres. La conception de haut niveau se concentre sur la manière dont le
système et tous ses composants peuvent être mis en œuvre sous forme de modules.
Il reconnaît la structure modulaire de chaque sous-système et leur relation et
interaction entre eux.
- Conception détaillée-La conception détaillée traite de la partie mise en œuvre de ce qui

est considéré comme un système et de ses sous-systèmes dans les deux conceptions
précédentes. Il est plus détaillé vers les modules et leurs implémentations. Il définit la
structure logique de chaque module et leurs interfaces pour communiquer avec d'autres
modules.
91
Modularisation
La modularisation est une technique permettant de diviser un système logiciel en plusieurs modules
discrets et indépendants, censés être capables d'effectuer des tâches de manière indépendante. Ces
modules peuvent fonctionner comme des constructions de base pour l'ensemble du logiciel. Les
concepteurs ont tendance à concevoir des modules tels qu'ils puissent être exécutés et/ou compilés
séparément et indépendamment.
La conception modulaire suit involontairement la règle de la stratégie de résolution de

problèmes «diviser pour mieux régner», car il existe de nombreux autres avantages liés à la
conception modulaire d'un logiciel.
Avantage de la modularisation :
- Les composants plus petits sont plus faciles à entretenir Le programme
- peut être divisé en fonction des aspects fonctionnels Le niveau
- d'abstraction souhaité peut être introduit dans le programme Les
- composants à haute cohésion peuvent être réutilisés L'exécution
- simultanée peut être rendue possible
- Désiré du point de vue de la sécurité
Concurrence
À l'époque, tous les logiciels sont censés être exécutés de manière séquentielle. Par exécution
séquentielle, nous entendons que l'instruction codée sera exécutée l'une après l'autre, ce qui
implique qu'une seule partie du programme est activée à un instant donné. Supposons qu'un
logiciel comporte plusieurs modules, alors un seul de tous les modules peut être trouvé actif à
tout moment de l'exécution.
Dans la conception de logiciels, la concurrence est mise en œuvre en divisant le logiciel en

plusieurs unités d'exécution indépendantes, comme des modules et en les exécutant en
parallèle. En d'autres termes, la concurrence permet au logiciel d'exécuter plusieurs parties
de code en parallèle les unes par rapport aux autres.
Il est nécessaire que les programmeurs et les concepteurs reconnaissent ces modules, qui
peuvent être exécutés en parallèle.
Exemple
La fonction de vérification orthographique du traitement de texte est un module logiciel qui s'exécute
parallèlement au traitement de texte lui-même.
37
Couplage et Cohésion
Lorsqu'un logiciel est modularisé, ses tâches sont divisées en plusieurs modules en fonction de
certaines caractéristiques. Comme nous le savons, les modules sont des ensembles
d'instructions assemblées afin de réaliser certaines tâches. Ils sont cependant considérés
comme une seule entité mais peuvent se référer les uns aux autres pour travailler ensemble. Il
existe des mesures par lesquelles la qualité d'une conception de modules et leur interaction
entre eux peuvent être mesurées. Ces mesures sont appelées couplage et cohésion.
Cohésion
La cohésion est une mesure qui définit le degré d'intra-fiabilité au sein des éléments d'un
module. Plus la cohésion est grande, meilleure est la conception du programme.
Il existe sept types de cohésion, à savoir –
- Cohésion fortuite -Il s'agit d'une cohésion non planifiée et aléatoire, qui pourrait
résulter de la division du programme en modules plus petits dans un souci de
modularisation. Parce qu'il n'est pas planifié, il peut semer la confusion chez les
programmeurs et n'est généralement pas accepté.
- Cohésion logique -Lorsque des éléments catégorisés logiquement sont rassemblés dans un
module, cela s'appelle la cohésion logique.
- Cohésion impériale -Lorsque des éléments de module sont organisés de manière à

être traités à un moment similaire, on parle de cohésion temporelle.
- Cohésion procédurale -Lorsque des éléments de module sont regroupés, qui sont
exécutés séquentiellement afin d'effectuer une tâche, on parle de cohésion
procédurale.
- Cohésion communicationnelle -Lorsque des éléments de module sont regroupés,

qui sont exécutés séquentiellement et travaillent sur les mêmes données
(informations), on parle de cohésion communicationnelle.
- Cohésion séquentielle -Lorsque des éléments de module sont regroupés parce que
la sortie d'un élément sert d'entrée à un autre et ainsi de suite, on parle de cohésion
séquentielle.
- Cohésion fonctionnelle -Il est considéré comme le plus haut degré de cohésion, et
il est très attendu. Les éléments de module en cohésion fonctionnelle sont
regroupés car ils contribuent tous à une même fonction bien définie. Il peut
également être réutilisé.
38
Couplage
Le couplage est une mesure qui définit le niveau d'interdépendance entre les modules d'un
programme. Il indique à quel niveau les modules interfèrent et interagissent les uns avec les
autres. Plus le couplage est faible, meilleur est le programme.
Il existe cinq niveaux de couplage, à savoir -
- Couplage de contenu -Lorsqu'un module peut directement accéder ou modifier ou se

référer au contenu d'un autre module, on parle de couplage au niveau du contenu.
- Couplage commun-Lorsque plusieurs modules ont un accès en lecture et en écriture à

certaines données globales, on parle de couplage commun ou global.
- Couplage de contrôle-Deux modules sont dits couplés au contrôle si l'un d'eux

décide de la fonction de l'autre module ou change son flux d'exécution.
- Timbre couplage-Lorsque plusieurs modules partagent une structure de données commune et

travaillent sur différentes parties de celle-ci, cela s'appelle le couplage de timbres.
- Couplage de données-Le couplage de données se produit lorsque deux modules interagissent

l'un avec l'autre au moyen de la transmission de données (en tant que paramètre). Si un module
passe la structure de données en paramètre, le module récepteur doit utiliser tous ses
composants.
Idéalement, aucun couplage n'est considéré comme le meilleur.
Vérification de la conception
Le résultat du processus de conception de logiciels est une documentation de conception, des pseudo-codes, des
diagrammes logiques détaillés, des diagrammes de processus et une description détaillée de toutes les
exigences fonctionnelles ou non fonctionnelles.
La phase suivante, qui est la mise en œuvre du logiciel, dépend de tous les extrants
mentionnés ci-dessus.
Il devient alors nécessaire de vérifier la sortie avant de passer à la phase suivante. Plus une
erreur est détectée tôt, mieux elle est ou elle pourrait ne pas être détectée avant le test du
produit. Si les résultats de la phase de conception sont sous forme de notation formelle,
leurs outils de vérification associés doivent être utilisés, sinon une revue de conception
approfondie peut être utilisée pour la vérification et la validation.
Grâce à une approche de vérification structurée, les examinateurs peuvent détecter les défauts qui pourraient
être causés par l'omission de certaines conditions. Une bonne revue de conception est importante pour une
bonne conception, précision et qualité du logiciel.
39
40
Analyse de logiciels et
Outils de conception 6
L'analyse et la conception de logiciels comprennent toutes les activités qui contribuent à la
transformation de la spécification des exigences en mise en œuvre. Les spécifications des
exigences spécifient toutes les attentes fonctionnelles et non fonctionnelles du logiciel. Ces
spécifications d'exigences se présentent sous la forme de documents lisibles et
compréhensibles par l'homme, auxquels un ordinateur n'a rien à voir.
L'analyse et la conception de logiciels constituent l'étape intermédiaire, qui aide les

exigences lisibles par l'homme à être transformées en code réel.
Voyons quelques outils d'analyse et de conception utilisés par les concepteurs de logiciels :
Diagramme de flux de données
Le diagramme de flux de données (DFD) est une représentation graphique du flux de données dans
un système d'information. Il est capable de représenter le flux de données entrant, le flux de
données sortant et les données stockées. Le DFD ne mentionne rien sur la façon dont les données
circulent dans le système.
Il existe une différence importante entre DFD et Flowchart. L'organigramme décrit le flux de contrôle
dans les modules de programme. Les DFD décrivent le flux de données dans le système à différents
niveaux. Il ne contient aucun élément de contrôle ou de branche.
Types de DFD
Les diagrammes de flux de données sont soit logiques, soit physiques.
- DFD logique-Ce type de DFD se concentre sur le processus système et le flux de

données dans le système. Par exemple, dans un système logiciel bancaire, comment les
données sont déplacées entre différentes entités.
- DFD physique-Ce type de DFD montre comment le flux de données est réellement
implémenté dans le système. Il est plus spécifique et proche de la mise en œuvre.
Composants DFD
DFD peut représenter la source, la destination, le stockage et le flux de données à l'aide de
l'ensemble de composants suivant :
91
- Entités-Les entités sont des sources et des destinations de données d'information. Les
entités sont représentées par des rectangles avec leurs noms respectifs.
- Processus-Les activités et les actions entreprises sur les données sont représentées par des cercles ou
des rectangles à bords arrondis.
- Stockage de données-Il existe deux variantes de stockage de données - il peut être

représenté soit sous la forme d'un rectangle sans les deux petits côtés, soit sous la forme
d'un rectangle à côtés ouverts avec un seul côté manquant.
- Flux de données-Le mouvement des données est indiqué par des flèches pointues. Le
mouvement des données est indiqué à partir de la base de la flèche comme source vers la tête de
la flèche comme destination.
Niveaux de DFD
- Niveau 0-Le niveau d'abstraction le plus élevé DFD est connu sous le nom de DFD de niveau 0, qui décrit
l'ensemble du système d'information sous la forme d'un diagramme masquant tous les détails sous-
jacents. Les DFD de niveau 0 sont également appelés DFD de niveau contextuel.
- Niveau 1-Le DFD de niveau 0 est divisé en DFD de niveau 1 plus spécifiques. Le DFD de
niveau 1 décrit les modules de base du système et le flux de données entre les différents
modules. Le niveau 1 DFD mentionne également les processus de base et les sources
d'information.
42

Software Engineering

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Engineering

Transféré par

Droits d'auteur :

Formats disponibles

Traduit de Anglais vers Français - www.onlinedoctranslator.

Tutoriel de génie logiciel

Droits d'auteur et clause de non-responsabilité

-Copyright 2014 par Tutoriels Point (I) Pvt. Ltd.

PUBLIC................................................. .................................................. ..................................JE

CONDITIONS PRÉALABLES ................................................. .................................................. ..........................JE

DROITS D'AUTEUR ET AVIS DE NON-RESPONSABILITÉ............................................ .................................................. ...........JE

APERÇU DU LOGICIEL ................................................................ .................................................. ...............1

GESTION DE PROJET LOGICIEL .................................................................. .................................................. 15

LOGICIELS REQUIS ................................................ .................................................. ..... 27

OUTILS LOGICIELS D'ANALYSE ET DE CONCEPTION......................................... ..................................... 41

STRATÉGIES DE CONCEPTION DE LOGICIELS ....................................... .................................................. 54

CONCEPTION DE L'INTERFACE UTILISATEUR DU LOGICIEL ...................................... .................................................. 58

COMPLEXITÉ DE LA CONCEPTION DU LOGICIEL ...................................... .................................................. 67

MISE EN ŒUVRE DU LOGICIEL ....................................................... .................................................. 74

VUE D'ENSEMBLE DES TESTS DE LOGICIELS ................................................. .................................................. 80

VUE D'ENSEMBLE DE LA MAINTENANCE DU LOGICIEL .................................. ....................................... 87

VUE D'ENSEMBLE DES OUTILS DU COFFRET LOGICIEL .................................................. .................................................. 100

Génie logicielest une branche d'ingénierie associée au développement de produits logiciels

(1) L'application d'une approche systématique, disciplinée et quantifiable au

(2) L'étude des approches comme dans l'énoncé ci-dessus.

Fritz Bauer, un informaticien allemand, définit le génie logiciel comme :

"L'ingénierie logicielle est l'établissement et l'utilisation de principes d'ingénierie

Lois d'évolution des logiciels

Évolution du logiciel E-Type

3.Conservation de la familiarité -La familiarité avec le logiciel ou la connaissance de la

4.Croissance continue-Pour un système de type E destiné à résoudre certains

6.Systèmes de rétroaction-Les systèmes logiciels de type E constituent des systèmes de

7.Autorégulation -Les processus d'évolution du système de type E s'autorégulent avec

ensemble du paradigme de développement logiciel.

Paradigme de développement logiciel

- Recueil des besoins

Paradigme de conception de logiciels

Besoin de génie logiciel

- Coût-Comme l'industrie du matériel informatique a montré ses compétences et l'énorme

- Nature dynamique-La nature toujours croissante et adaptative du logiciel dépend

- Gestion de la qualité-Un meilleur processus de développement logiciel fournit un

Caractéristiques d'un bon logiciel

Cycle de vie du développement logiciel

Recueil des exigences

- étudier le système et les logiciels existants ou obsolètes, mener des

- entretiens avec les utilisateurs et les développeurs, se référer à la

- recueillir les réponses des questionnaires.

Paradigme de développement logiciel

Cela rend la vérification et la validation en parallèle. Ce modèle est également appelé

Modèle Big Bang

Gestion de projet logiciel

- une activité de routine ou une opération quotidienne. Le projet est livré

- avec une heure de début et de fin.

- Le projet a besoin de ressources adéquates en termes de temps, de main-d'œuvre, de financement, de

Besoin de gestion de projet logiciel

Chef de projet logiciel

Un chef de projet surveille de près le processus de développement, prépare et exécute

Voyons quelques responsabilités qu'un chef de projet assume -

Gérer des gens

- parties prenantes Gestion des ressources

- humaines Mise en place de la hiérarchie

- Gestion des activités de gestion de projet Suivi des

- progrès et des performances Analyse des risques

- en tant que porte-parole du projet

Activités de gestion de logiciels

Lors de la gestion du périmètre du projet, il est nécessaire de -

- Décider de sa vérification et de son contrôle