Vous êtes sur la page 1sur 33

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université Abderrahmane Mira de Bejaia


Faculté des Sciences Exactes
Département d’Informatique

Cours Génie logiciel


Réalisé par: Dr. YESSAD Nawal Ep. OUATAH

Niveau : L3

Année universitaire 2019/2020


Cours Génie logiciel

 Public Cible : étudiants de 3ème année Licence en Informatique.


 Volume horaire global : 45 Heures
 Coefficient : 02
 Crédit : 04
Objectifs du cours

 Présenter un aperçu de l'état de l'art en matière de génie logiciel.

 Exposer les principaux courants de pensées en matière de développement logiciel.

 Proposer un ensemble de pratiques pragmatiques qui permettent de survivre à un projet de


développement de logiciel.

 Méthodologies permettant de mener à bien un projet informatique complexe et en équipe

 Découpage de problèmes difficiles en plusieurs petits problèmes plus faciles à traiter

 Comprendre la nécessité et l’utilité des méthodes du génie logiciel

 Savoir documenter toutes les étapes de la conception d’une application

 Aborder les différents aspects de l’approche UML


Contenu du module

 Chapitre I: Introduction au génie logiciel


 Chapitre II: Introduction à la conception orientée objets
 Chapitre III: Présentation du langage de modélisation UML
 Chapitre IV: Présentation des diagrammes d’UML
Chapitre I: Introduction au génie logiciel
Plan

 Introduction
 Crise de logiciel
 Raisons de la faible qualité des logiciels
 Définition du terme « Génie Logiciel»
 Objectifs et principes du GL
 Terminologie
 Commet fabriquer un bon logiciel ?
 Catégories de logiciels
 Schéma général d’un processus de développement
 Modèles de Cycle de vie
 Méthodes agiles
 Tests logiciel
 Conclusion
Introduction

Naissance du Génie Logiciel…

 Les pères du Génie Logiciel (Software Engineering) se prénomment Friedrich Bauer et Louis Bolliet. Cette spécialité a
en effet vu le jour entre le 7 et le 11 octobre 1968, à Garmisch-Partenkirchen, sous le parrainage de l’OTAN.

Elle avait pour objectif de répondre à 2 constations :


1. d’une part, le logiciel n’était pas fiable,
2. d’autre part, il était difficile à réaliser dans les délais et budgets prévus et en satisfaisant le cahier des charges.

 En 1993, la branche informatique (Computer Society) de l’IEEE (Institute of Electrical and Electronics Engineers) et
l’ACM (Organisation professionnelle américaine des informaticiens) ont établi un comité conjoint dont la tâche était de
définir un ensemble de critères et de normes appropriés pour la pratique professionnelle du Génie Logiciel.
Crise du logiciel

 Le terme de Génie Logiciel a été introduit à la fin des années 60 lors d’une conférence tenue pour
discuter de ce que l’on appelait "la crise du logiciel".

 Les symptômes les plus caractéristiques de cette crise sont:

1. les logiciels réalisés ne correspondent souvent pas aux besoins des utilisateurs;
2. les logiciels contiennent trop d'erreurs (qualité du logiciel insuffisante);
3. les coûts du développement sont rarement prévisibles et sont généralement exagérés;
4. la maintenance des logiciels est une tâche complexe et coûteuse;
5. les délais de réalisation sont généralement dépassés;
6. les logiciels sont rarement portables.

Tous ces problèmes ont mené à l’émergence d’une discipline appelée le Génie Logiciel.
Raisons de la faible qualité des logiciels

Mauvaise compréhension des besoins


Négligence de la phase d'analyse des besoins du client
Manque d'implication du client dans le processus
communication difficile entre personnes de métiers
différents
Tâche complexe

Taille et complexité des logiciels


Taille des équipes de conception/développement

Manque de méthodes et de rigueur


Manque de méthodes de conception
Négligence et manque de méthodes et d'outils des phases de validation/vérification

Difficultés spécifiques du logiciel


Produit invisible et immatériel
Mises à jour et maintenance dues à l'évolution rapide de la technologie
Défaillances logicielles principalement humaines
Définition du terme « Génie Logiciel»

Le Génie Logiciel est l’application Le terme Génie Logiciel (en anglais


d’une approche systématique, software engineering) désigne
disciplinée et quantifiable au l’ensemble des méthodes, des
développement, à l’exploitation et à techniques et outils contribuant à la
la maintenance du logiciel. C’est-à- production d’un logiciel de qualité
dire, l’application de l’ingénierie au avec maîtrise des coûts et délais.
logiciel.
Norme IEEE 610.12
Génie logiciel

Le Génie Logiciel est l’art et la science


Le Génie Logiciel est une discipline de concevoir et de construire, avec
qui a pour but la fabrication du économie et élégance, des
logiciel sans faute, livré dans le applications, des objets et d’autres
délai et le budget prévus à systèmes informatiques, qui soient
l’avance, et qui satisfait aux corrects, robustes, extensibles,
besoins du client. réutilisables, sûrs, efficaces, faciles à
maintenir et à utiliser.
Objectifs du GL

 Avoir des procédures systématiques pour des logiciels de grande taille afin que
• la spécification corresponde aux besoins réels du client
• le logiciel respecte sa spécification
• les délais et les coûts alloués à la réalisation soient respectés

Pour
Les principes du génie logiciel
 La rigueur : Les principales sources de défaillances d’un logiciel sont d’origine humaine. Des outils de
vérification accompagnant le développement peuvent aider à réduire les erreurs.

 La décomposition des problèmes en sous-problèmes : Il s’agit de : Décarreler les problèmes pour n’en
traiter qu’un seul à la fois et simplifier les problèmes pour aborder leur complexité progressivement.

 La modularité : C’est une instance cruciale du principe de décomposition des problèmes. Il s’agit de
partitionner le logiciel en modules qui ont une cohérence interne et qui possèdent une interfacene
divulguant sur le contenu du module.

 L’abstraction : C’est encore une instance du principe de décomposition des problèmes. Il s’agit d’exhiber
des concepts généraux regroupant un certain nombre de cas particuliers et de raisonner sur ces concepts
généraux plutôt que sur chacun des cas particuliers.

 L’anticipation des évolutions : Un logiciel a un cycle de vie plus complexe que l’habituel .La maintenance
est la gestion des évolutions du logiciel. Il est primordial de prévoir les évolutions possibles d’un logiciel
pour que la maintenance soit la plus efficace possible.

 La généricité : Un logiciel réutilisable a beaucoup plus de valeur qu’un composant dédié. Un composant est
générique lors qu’il est adaptable.

 La construction incrémentale : Un développement logiciel a plus de chances d’aboutir si il suit une


cheminement incrémental.
Terminologie

Logiciel
est un ensemble d’entités nécessaires au fonctionnement
d’un processus de traitement automatique de l’information.
Parmi ces entités, on trouve par exemple : des programmes;
des documentations d’utilisation ; des informations de
configuration;
Modèle
est une représentation schématique de la réalité.
Les modèles décrivent les liens, les relations entre les
Projet différentes étapes du cycle de vie du logiciel.

Ensemble d’activités organisées permettant de créer un


produit ou un service unique avec une qualité définie dans le
cadre d’un budget fixé Il s’agit d’un effort temporaire
caractérisé notamment par un début et une fin déterminés
Processus
Un processus de développement logiciel est un ensemble
(structuré) d’activités que conduisent à la production d’un
Cycle de vie logiciel
Ensemble séquentiel de phases, dont le nom et le nombre
sont déterminés en fonction des besoins du projet,
permettant généralement le développement d’un logiciel
Comment fabriquer un logiciel de qualité ?

Un logiciel est dit de qualité s'il remplit au moins les critères suivants :

Fiabilité (ou
Maintenabilité Efficacité Utilisabilité
robustesse)

Le logiciel est-il sujet à Le logiciel fait-il bon


Peut-on faire évoluer Est-il facile à utiliser ?
des usage de ses
le logiciel ?
dysfonctionnements ? ressources ?

Le logiciel fonctionne
Elle est liée à la facilité
raisonnablement en On dit d’un logiciel
toutes circonstances, qu’il est efficace s’il d’apprentissage,
Elle correspond au d’utilisation,
rien de utilise les ressources
degré de facilité de la d’interprétation des
catastrophique ne d’une manière
maintenance d’un erreurs et de
peut survenir, même optimale (comme la
produit logiciel.
en dehors des mémoire par rattrapage en cas
conditions exemple). d’erreur d’utilisation.
d'utilisation prévues.
Catégories de logiciels

 Il existe 2 catégories des logiciels notamment :

Logiciels génériques Logiciels Spécifiques


Ce sont des logiciels qui vendus comme les produits ce sont des logiciels développés pour une application
courants sur le marché informatique. précise et destinés à un seul client. Dans cette
catégorie, on en distingue autant :
Dans cette catégorie, on en distingue autant :
 Logiciels essentiels au fonctionnement d'une
 Logiciels amateurs : Il s’agit de logiciels développés entreprise : Ce type de logiciel est le fruit d'un
par des « amateurs6» . ce sont des logiciels sans investissement non négligeable et doit avoir un
impact économique significatif sur l’ensemble. comportement fiable, sûr et sécurisé.

 Logiciels « jetables » ou « consommables » : Il  Logiciels critiques : Il s’agit de logiciels dont


s’agit de logiciels comme par exemple les logiciels l’exécution est vitale, pour lesquels une erreur
des traitements de texte ou les tableurs pour les peut coûter très cher ou coûter des vies humaines.
entreprises. Ces logiciels ne coûtent pas très cher, et Exemple : domaines du transport, de l’aviation, de
peuvent être remplacés facilement au sein d’une la médecine, de l’armement, etc.
entreprise sans engendrer des risques majeurs.
Schéma général d’un processus de développement

Spécification Données complètes et précises

Analyse descendante Décomposition fonctionnelle

Implémentation Langage de programmation

Validation Jeux d’essai


Schéma général d’un processus de développement
Établir une description claire de ce que doit faire le logiciel
Clarifier le cahier des charges (ambiguïtés, contradictions)
Spécification enlistant les exigences fonctionnelles et non fonctionnelles

Apport de solutions techniques:


Expression des besoins architecture, performance et
Définition d’un cahier des Analyse des optimisation
Conception
charges besoins
Définition des structures et des
algorithmes

Quoi faire » : comprendre Tests de vérification: Vérification


et modéliser le métier Phases des processus de la robustesse et cohérence du
Identifier les éléments système
Analyse du
intervenants système
validation validation client : accord avec les
besoins (correspondance avec le
cahier des charges)

Correction des erreurs du


système et demande d’évolution
Placer la squelette du code à partir Implémentation maintenance (modification de
du modèle système) l’environnement technique,
Réalisation et programmation nouvelle fonctionnalité)
Schéma général d’un processus de développement
Conception
Analyse des besoins  Comment faire le système : choix techniques
 Etape préalable si le client n’a qu’une idée peu précise du système à  Choix d’une architecture technique (matériel, logiciel) suivant certaines priorités
réaliser (facteurs
 Etude informelle des fonctionnalités (externes) du système sans  qualités : robustesse, efficacité, portabilité…)
considération technique : point de vue métier / utilisateur  Expertise informatique : hors compréhension du client
 Dialogue fournisseur / client en termes intelligibles  Modèle de l’architecture logicielle du système
 pour ce dernier : l’aider à formaliser le problème à résoudre  Décomposition en sous-systèmes : application (interfaces), domaine (métier) et
 Produire un document textuel avec schémas… infrastructure (implémentation)
 Conduit généralement à la définition du cahier des charges  Permet la définition des phases d’implémentation,
 de validation et de maintenance

Analyse du système Implémentation


« Quoi faire » : comprendre et modéliser le métier
 Souvent trop de temps consacré au codage au détriment des phases d’analyse et de
 Réflexion métier hors de toute considération technique
conception :
 Reste un support de discussion avec le client / utilisateur
 mauvaise pratique parfois très coûteuse…
 Premier modèle du système (niveau métier)
 Savoir user de la réutilisation de composants,
 Identifier les éléments intervenants (hors acteurs) et dans le système :
 voire d’outils de génération de code (mise en place automatique du squelette du code à
fonctionnalités, structures et relations, états par lesquels ils passent
partir du modèle système)
suivant
 l’activité de développement sera de plus en plus tournée vers la réutilisation de
 certains événements (diagramme de classes, de collaboration)
composants existants
 L’analyse n’est jamais complète mais elle doit être juste

Spécification
 Ce que doit faire le système (côté client)
 Document précis spécifiant les fonctionnalités attendues Validation
 Base du contrat commercial avec le client  Vérification de la robustesse et cohérence du
 Document facile à comprendre par le client / utilisateur système en particulier dans le cas d’exception
 spécifications ne sont jamais complètes ni définitives  Logiciels de tests : toute ligne de code doit être
 Evolution du domaine, besoins supplémentaires… testée
Schéma général d’un processus de développement

Analyse des besoins


Activité Etude préalable
Description Etudier la faisabilité du projet, ses contraintes techniques (
coût, temps, qualité ) et les alternatives possibles

Entrée ¨Problème à résoudre, objectifs à atteindre


Sorties OUI (la décision est prise de réaliser le logicile ) ou NON (le
projet est abandonné )

Spécification (QUOI?)
Activité Spécifier
Description Décrire ce que doit faire le logiciel (comportement en boite
noire). Décrire comment vérifier en boite noire que le logiciel
fait bien ce qui est exigé.
Entrée Client qui a une idée de ce qu’il veut exigences, besoins …
concernant le système permettant de résoudre le problème
Sorties Cahier des charges du logiciel (spécifications du logiciel ). Des
procédures de validation. Version provisoire des manuels
d’utilisation et d’exploitation de logieciel
Schéma général d’un processus de développement
Conception
Activité Concevoir
Description Activité Description Entrées Sorties Organiser le logiciel afin qu’il puisse satisfaire les exigences
de la spécification.
Faire les principaux choix techniques pour satisfaire les
exigences de la spécification.
Entrée Une spécification.
Sorties Une description des décisions de conception. Des procédures
de tests qui permettent de vérifier que les décisions de
conception sont correctement implémentées en code
source et qu’elles contribuent à satisfaire les exigences de la
spécification.

Implémentation
Activité Coder et tester
Description Ecrire le code source du logiciel. Tester le comportement du
code source afin de vérifier qu’il réalise les responsabilités
qui lui sont allouées.
Entrée Spécification, conception.
Sorties Code source. Tests unitaire. Documentation.
Schéma général d’un processus de développement

Validation
Activité Valider
Description Description Construire le logiciel complet exécutable.
Dérouler les tests de validation sur le
logiciel complet exécutable.
Entrée Logiciel complet exécutable à valider. Tests de validation.
Sorties Rapport de tests de validation.

Maintenance
Activité Corriger
Description Correction des erreurs du système et demande d’évolution
(modification de
l’environnement technique, nouvelle fonctionnalité)
Entrée Logiciel complet.
Sorties Logiciel corrigé ; Mises à jour ; Documents corrigés.
Modèles de Cycle de vie

 Le Cycle de vie du développement d’un logiciel est un ensemble d’étapes de la réalisation, de l’énoncé
des besoins à la maintenance au retrait du logiciel sur le marché informatique.

 De façon générale, on peut dire que le cycle de vie du logiciel est la période de temps s’étalant du
début à la fin du processus du logiciel. Il commence donc avec a proposition ou la décision de
développer un logiciel et se termine avec sa mise hors service.

 L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant plus élevé qu’elles
sont détectées tardivement dans le processus de réalisation. C’est ainsi que l’objectif principal du cycle
de vie du développement d’un logiciel est de permettre la détection des erreurs au plus tôt et par
conséquent, maîtriser la qualité du produit, les délais de sa réalisation et les coûts associés.

 Il existe plusieurs modèles de cycle de vie d’un logiciel à savoir


Modèle en Cascade
Modèle en V
Modèle en Spiral
Modèles de Cycle de vie
Modèle en " Cascade" (waterfall model)

Etude de faisabilité

Définition des besoins

Conception générale

• Le cycle de vie dit de la « cascade » date de 1970, il est l’œuvre de Royce.


• Ce Cycle de vie est linéaire (présentoir) sans aucune évaluation entre le début Conception détaillée
du projet et la validation.
Codage
• Le projet est découpé en phases successives dans le temps et à chaque phase
correspond une activité principale bien précise produisant un certain nombre
de livrables Intégration
• On ne passe à l’étape suivante que si les résultats de l’étape précédente sont
jugés satisfaisants. Implémentation
• L’activité d’une étape se réalise avec les résultats fournis par l’étape
précédente ; ainsi, chaque étape sert de contrôle du travail effectué lors de
l’étape précédente et Chaque phase ne peut remettre en cause que la phase
précédente ce qui, dans la pratique, s’avère insuffisant.
Modèles de Cycle de vie
Modèle en " Cascade" (waterfall model)

Etude de faisabilité

• les erreurs de spécifications sont généralement détectées Définition des besoins


au moment des tests, voire au moment de la livraison du
logiciel à l’utilisateur. Conception générale

 Leur correction nécessite alors de reprendre toutes les


Conception détaillée
phases du processus.
Codage
 Dans le modèle en cascade, on effectue les différentes
étapes du logiciel de façon séquentielle. Les interactions
Intégration
ont lieu uniquement entre étapes successives : on
s’autorise des retours en arrière uniquement sur l’´étape
précédente. Par exemple, un test ne doit pas remettre en Implémentation
cause la conception architecturale.
Modèles de Cycle de vie
Modèle en V
 Dérivé du modèle de la cascade, le modèle en V du cycle de développement montre non seulement
l’enchaînement des phases successives, mais aussi les relations logiques entre phases plus éloignées.

 Le modèle en V du cycle de vie du logiciel précise la conception des tests :


les tests système sont préparés à partir de la spécification;
les tests d'intégrations sont préparés à partir de la conception architecturale ;
les tests unitaires sont préparés à partir de la conception détaillée des composants).
 La première branche correspond à un modèle en
cascade classique (enchaînement séquentiel)

 Les flèches discontinues représentent le fait


qu'une partie des résultats de l'étape de départ
est utilisée directement par l'étape d'arrivée,

 Avec les jeux de tests préparés dans la première


branche, les étapes de la deuxième branche
peuvent être mieux préparées et planifiées. La
seconde branche correspond à des tests effectifs
effectués sur des composants réalisés.
Modèles de Cycle de vie
Modèle en spiral

 Fournir le plus rapidement possible un prototype exécutable permettant une validation concrète et
non sur document
 Progression du projet par incrémentations successives de versions du prototype : itérations

 Chaque itération donne lieu à une contractualisation préalable, s’appuyant sur les besoins exprimés lors
de l’itération précédente.
 Une itération comporte :
-l’élaboration d’objectifs
-Analyse du risque ;
-Développement d'un prototype (modèle,) ;
-Simulation et essais du prototype ;
-Détermination des besoins à partir des résultats des essais ;
-Validation des besoins par un comité de pilotage ;
-Planification de l’itération suivante.
Modèles de Cycle de vie
Modèle en spiral
Dans le modèle en spiral les risques, quels qu’ils soient, sont constamment traités au travers de bouclages
successifs

 Chaque spire confirme et affine les spires précédentes en menant des activités de même nature
successivement ;

 L’analyse ou la conception ne sont plus effectuées dans une seule phase ou étape mais sont conduites en
tant qu’activités qui se déroulent sur de multiples phases ;

 A chaque étape, après avoir défini les objectifs et les alternatives, celles-ci sont évaluées par différentes
techniques (prototypage, simulation, ...), l’étape est réalisée et la suite est planifiée.

 Il n’est pas nécessaire d’adopter un seul modèle à chaque cycle de la spirale ou même pour l’ensemble
d’un système. Le modèle de la spirale englobe tous les autres modèles.

 Le prototypage peut être utilisé dans une spirale pour résoudre le problème de la spécification des
besoins, puis il peut être suivi d’un développement basé sur le modèle conventionnel de la cascade.
Méthodes agiles

 Les méthodes de développement dites « méthodes agiles »(en anglais Agile Modeling, noté AG) visent
à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version
minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et
des tests tout au long du cycle de développement.

 L'origine des méthodes agiles est liée à l'instabilité de l'environnement technologique et au fait que le
client est souvent dans l'incapacité de définir ses besoins de manière exhaustive dès le début du
projet.

 Le terme « agile » fait ainsi référence à la capacité d'adaptation aux changements de contexte et aux
modifications de spécifications intervenant pendant le processus de développement.

 Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient très vite une
première mise en production de son logiciel. Ainsi, il est possible d'associer les utilisateurs dès le
début du projet

 Nous présentons quelques méthodes agiles:


Méthodes agiles

 RAD - Développement rapide d'applications : (en anglais Rapid Application Development, notée RAD),
consiste en un cycle de développement court basé sur 3 phases (Cadrage, Design et Construction) dans un
délai idéal de 90 jours et de 120 jours au maximum.

 DSDM (Dynamic Software Development Method): a été mise au point en s'appuyant sur la méthode RAD afin
de combler certaines de ses lacunes, notamment en offrant un canevas prenant en compte l'ensemble du
cycle de développement. Les principes fondateurs de la méthode DSDM sont les suivants :
•Une implication des utilisateurs
•Un développement itératif et incrémental
•Une fréquence de livraison élevée
•L'intégration des tests au sein de chaque étape
•L'acceptation des produits livrés dépend directement de la satisfaction des besoins

UP - Unified Process: (UP pour Unified Process) est un processus de développement itératif et incrémental, ce
qui signifie que le projet est découpé en phases très courtes à l'issue de chacune desquelles une nouvelle
version incrémentée est livrée. Il s'agit d'une démarche s'appuyant sur la modélisation UML pour la description
de l'architecture du logiciel (fonctionnelle, logicielle et physique) et la mise au point de cas d'utilisation
permettant de décrire les besoins et exigences des utilisateurs.
Méthodes agiles

 RUP - Rational Unified Process (Rational Unified Process) est une méthode de développement par itérations
promue par la société Rational Software, rachetée par IBM. RUP propose une méthode spécifiant notamment
la composition des équipes et le calendrier ainsi qu'un certain nombre de modèles de documents.

 XP - eXtreme Programming : définit un certain nombre de bonnes pratiques permettant de développer un


logiciel dans des conditions optimales en plaçant le client au coeur du processus de développement, en
relation étroite avec le client. L'eXtreme Programming est notamment basé sur les concepts suivants :
•Les équipes de développement travaille directement avec le client sur des cycles très courts d'une à deux
semaines maximum.
•Les livraisons de versions du logiciel interviennent très tôt et à une
fréquence élevée pour maximiser l'impact des retours utilisateurs.
•L'équipe de développement travaille en collaboration totale sur la base de binômes..
•Le code est testé et nettoyé tout au long du processus de développement.
•Des indicateurs permettent de mesure l'avancement du projet afind e permettre de mettre à jour le plan de
développement.
Tests du logiciel

 Le test d'une application peut être manuel. Dans ce cas, une personne effectue sur l'application une suite
d'opérations prévue à l'avance (navigation, connexion, envoi d'informations...) pour vérifier qu'elle
possède bien le comportement attendu. C'est un processus coûteux en temps et sujets aux erreurs
(oublis, négligences, etc.). En complément de ces tests manuels, on a tout intérêt à intégrer à un projet
logiciel des tests automatisés qui pourront être lancés aussi souvent que nécessaire.

 les tests logiciels peuvent être présentés en différentes catégories :


Tests du logiciel
Tests de validations
Ces tests sont réalisés lors de la recette (validation) par un client d'un projet livré par l'un de ses
fournisseurs. Souvent écrits par le client lui-même, ils portent sur l'ensemble du logiciel et permet de
vérifier son comportement global en situation. De par leur spectre large et leur complexité, les tests de
validation sont le plus souvent manuels. Les procédures à suivre sont regroupées dans un document associé
au projet, fréquemment nommé plan de validation.

Tests d’intégrations
 l'intégration est de fait d'assembler plusieurs composants (ou modules) élémentaires en un composants
de plus haut niveau. Un test d'intégration valide les résultats des interactions entre plusieurs
composants permet de vérifier que leur assemblage s'est produit sans défaut. Il peut être manuel ou
automatisé. Un nombre croissant de projets logiciels mettent en place un processus d'intégration continue.
Cela consiste à vérifier que chaque modification ne produit pas de régression dans l'application
développée.

Tests unitaires
 Contrairement aux tests de validation et d'intégration qui testent des pans entiers d'un logiciel, un test
unitaire na valide qu'une portion atomique du code source (exemple : une seule classe) et est
systématiquement automatisé.
Conclusions
• Le génie logiciel est la science des bonnes pratiques de développement de logiciel. Cette science étudie en
particulier la répartition des phases dans le temps, les bonnes pratiques concernant les documents clés
que sont le cahier des charges, le diagramme d'architecture ou le diagramme de classes. Le but recherché
est d'obtenir des logiciels de grande ampleur qui soient fiables, de qualité, et correspondent aux attentes
de l'usager.
• Par contre, Le développement de logiciel consiste à étudier, concevoir, construire, transformer, mettre au
point, maintenir et améliorer des logiciels.
• Le développement d’une application exige de :
• Procéder par étapes, en prenant connaissance des besoins de l’utilisateur ; effectuer l’analyse ; trouver une
solution informatique ; réaliser ; tester ; installer et assurer le suivi.
• Procéder avec méthode, en partant du général aux détails et aux techniques ; fournir une documentation ;
s’aider de méthodes appropriées ; et Savoir se remettre en question.
• Choisir une bonne équipe, en trouvant les compétences adéquates ; définir les missions de chacun et
coordonner les différentes actions pour la construction du logiciel.
• Contrôler les coûts et délais, en considérant l’aspect économique ; maîtriser de la conduite du projet ; et
investissements aux bons moments.
• Garantir le succès du logiciel, en répondant à la demande et assurer la qualité du logiciel.