COURS de GL

Le Génie Logiciel (GL) est né en 1968 pour résoudre la crise du logiciel provoquée par l'arrivée des ordinateurs de la 3e
génération. Il vise à rationaliser la production de logiciels en appliquant des principes d'ingénierie pour répondre aux besoins du
client.

1. Définition

Logiciel = Le Logiciel est un ensemble de programmes permettant à un système informatique d'accomplir des tâches
spécifiques.
Ingénierie = L'Ingénierie est l'ensemble des fonctions de la conception à la construction d'une installation technique.
Génie logiciel = Le Génie logiciel est l'ensemble de connaissances et moyens visant à rationaliser la production de logiciels,
utilisant des principes d'ingénierie.

2. Objectifs du GL

Correspondance entre la spécification du logiciel et les besoins réels du client.

Respect des délais et des coûts.
Production de documentation pour l'installation, l'utilisation, le développement et la maintenance.
Assurer la qualité du logiciel sous différents aspects.

3. Méthodes du GL

Le GL comprend :

Des modèles pour représenter les éléments du logiciel.

Une démarche pour indiquer les étapes à suivre.
Une documentation structurée pour mémoriser les modèles et la démarche.

4. Les Outils du GL

Les "Ateliers de Génie Logiciel" (AGL) assistent les développeurs dans la gestion de projets informatiques. Ces outils aident à
représenter les modèles, à générer de la documentation technique, à normaliser les noms, à générer du code, à faciliter la
conduite de projet, la maintenance, le suivi d'exploitation, et le contrôle de qualité.

5. Critères de Qualité

Les critères de qualité du logiciel sont définis dans le Plan Qualité Logiciel (PQL).
Ils incluent des facteurs externes et internes (perceptibles par les informaticiens).
Les facteurs internes visent à améliorer les qualités externes.

6. Documentation

Quatre types de documentation sont produits:

docs contractuelle (le cahier des charges)

docs pour la conception et le dev (dossier technique)
docs au maintenance
docs destinée aux utilisateurs (guide d'utilisation, guide d'installation, dossier d'exploitation).

NOTION DE GL/OBJECTIF

Le génie logiciel (GL) vise à rationaliser la production de logiciels en appliquant des principes d'ingénierie. Son objectif principal
est de produire des logiciels de haute qualité qui correspondent aux spécifications du client tout en respectant les contraintes de
temps, budgets et la création de logiciels qui répond aux besoins des utilisateurs.
TEST BOITE BLANCHE/NOIRE

Le test de la Boîte blanche se concentre sur l'analyse de la structure interne du code source, en examinant les chemins
d'exécution, les branches, et les variables pour concevoir des cas de test et détecter les erreurs potentielles.

Le test de la Boîte noire se base sur les spécifications externes du logiciel, en élaborant des cas de test sans connaître la
structure interne, afin de vérifier les fonctionnalités selon les entrées et de garantir que le logiciel réponde aux exigences
énoncées.

MESURE DE COMPLEXITÉ DE MC CABE

La mesure de complexité de McCabe est une métrique qui évalue la complexité d'un programme informatique en comptant le
nombre de chemins d'exécution possibles à travers le code, ce qui peut aider à améliorer la qualité et la maintenabilité du
logiciel.

DIFFERENTES METRIQUES DE FIABILITE D'UN LOGICIEL + DESCRIPTION

Voici les métriques essentielles pour évaluer la fiabilité d'un logiciel:

1. Taux de défaillance (Failure Rate) : Mesure la fréquence des défaillances. Un taux élevé indique une faible fiabilité.

2. Temps moyen entre les pannes (Mean Time Between Failures - MTBF) : Représente la durée moyenne entre deux
défaillances successives. Un MTBF élevé indique une grande fiabilité.

3. Disponibilité (Availability) : Mesure la proportion de temps pendant laquelle le logiciel fonctionne sans défaillance. Une
disponibilité élevée signifie une grande fiabilité.

4. Temps moyen de réparation (Mean Time To Repair - MTTR) : Mesure le temps moyen nécessaire pour réparer un logiciel
après une défaillance. Un MTTR court contribue à une meilleure fiabilité.

5. Taux d'erreur résiduelle (Residual Error Rate) : Évalue la proportion d'erreurs qui subsistent dans le logiciel après la
correction des défaillances initiales.

6. Fiabilité du logiciel en fonction du temps (Time-Based Software Reliability) : Estime la fiabilité du logiciel au fil du temps,
en tenant compte des défaillances passées et de la durée d'utilisation.

POURQUOI TESTER UN LOGICIEL

Assurer la qualité : Les tests identifient et corrigent les erreurs et les bogues, ce qui améliore la qualité du logiciel.
Satisfaire les utilisateurs : Les tests vérifient que le logiciel fonctionne comme prévu, ce qui garantit la satisfaction des
utilisateurs.
Valider les exigences : Les tests s'assurent que le logiciel respecte les spécifications et les attentes des utilisateurs.
Garantir la sécurité : Les tests vérifient la sécurité du logiciel, protégeant ainsi les données et les utilisateurs.
Mesurer les performances : Les tests évaluent les performances du logiciel pour s'assurer qu'il fonctionne rapidement et
efficacement.
Éviter les coûts de maintenance : Les tests préviennent les erreurs coûteuses à corriger après le déploiement.
Assurer le succès : Le test garantit que le logiciel fonctionne bien dans son environnement opérationnel, ce qui favorise son
succès global.
DIFFÉRENCE ENTRE MISE AU POINT INDUCTIVE ET DÉDUCTIVE

La mise au point inductive et déductive sont deux approches de raisonnement ou de recherche qui diffèrent dans leur approche
et leur méthode.

Mise au point inductive

L'induction consiste à tirer des conclusions générales à partir d'observations spécifiques.

Il s'agit d'une approche basée sur des exemples ou des observations concrètes.
Les conclusions obtenues par induction ne sont pas nécessairement certaines, mais elles sont probables.

=> Exemple de raisonnement inductif (général): Si vous voyez de nombreux cygnes blancs, vous pourriez penser que tous les
cygnes sont blancs. Cependant, si vous trouvez un cygne noir, cette idée pourrait changer.

=> Exemple de raisonnement inductif (technique): Si votre antivirus n'a jamais trouvé de virus dans les fichiers de votre ami,
vous pourriez penser que ses fichiers sont sûrs. Mais cela ne signifie pas nécessairement que tous les fichiers de vos amis sont
toujours sûrs.

Mise au point déductive

La déduction consiste à tirer des conclusions spécifiques à partir de propositions générales ou de principes préalablement
établis.
Elle repose sur des règles de logique et des axiomes.

=> Raisonnement déductif (général): Par exemple, à partir des propositions générales "Tous les hommes sont mortels" et
"Socrate est un homme", on peut déduire de manière logique que "Socrate est mortel". Autre exemple, on peut déduire
mathématiquement des résultats tels que la somme de deux nombres pairs est toujours un nombre pair.

=> Raisonnement déductif (technique): Si vous oubliez votre mot de passe en ligne, vous pouvez utiliser la logique pour le
retrouver. Si vous savez quelles lettres et chiffres vous utilisez habituellement, vous pouvez les inclure dans votre recherche pour
le retrouver plus facilement.

FACTEURS DU COÛT DE LA MAINTENANCE

Complexité du logiciel : Plus le logiciel est compliqué, plus il est cher à entretenir.
Technologies obsolètes : Utiliser des vieilles technologies peut coûter plus cher car elles sont plus difficiles à entretenir.
Documentation : Si les explications sur le fonctionnement du logiciel sont bonnes et à jour, cela peut réduire les coûts de
maintenance.
Qualité du code source : Si le code est bien écrit et organisé, cela coûte moins cher à maintenir.
Taille de l'équipe de maintenance : Plus il y a de personnes pour réparer et mettre à jour le logiciel, plus cela coûte cher.
Fréquence des mises à jour : Si le logiciel nécessite souvent des mises à jour, cela peut coûter plus cher.
Compatibilité avec différentes technologies : Si le logiciel doit fonctionner sur de nombreux types d'ordinateurs ou de
smartphones, cela peut augmenter les coûts.
Sécurité : Assurer que le logiciel est sûr peut coûter plus cher.
Utilisation intensive : Si beaucoup de personnes utilisent beaucoup le logiciel, il peut être plus cher à maintenir.
Changements dans les besoins : Si les besoins des utilisateurs changent souvent, le logiciel doit être modifié, ce qui peut
augmenter les coûts.

PROCESSUS/GENRE DE TEST D'UN LOGICIEL

Pour développer un logiciel de [contexte...], il est essentiel de planifier des tests appropriés pour garantir la qualité et la fiabilité
du logiciel.
 1. Tests unitaires: Les tests unitaires se concentrent sur la vérification de chaque composant individuel du logiciel, comme les
fonctions ou les modules. Les développeurs écrivent des cas de test pour chaque fonction ou module et les exécutent pour
s'assurer qu'ils fonctionnent correctement.
2. Tests d'intégration: Les tests d'intégration vérifient comment les différents composants du logiciel fonctionnent ensemble
pour s'assurer qu'ils se coordonnent correctement et partagent des données de manière cohérente.
3. Tests fonctionnels: Les tests fonctionnels évaluent si le logiciel accomplit ses tâches conformément aux spécifications, pour
vérifier si le logiciel gère correctement [contexte...].
4. Tests d'acceptation: Les tests d'acceptation évaluent si le logiciel est prêt pour une utilisation réelle. Les utilisateurs finaux
du CNTEMAD participent à des tests de validation pour s'assurer que le logiciel répond à leurs besoins.
5. Tests de performance: Les tests de performance évaluent la réactivité et la stabilité du logiciel en situation de charge,
permettant de détecter les problèmes de performances, comme les ralentissements, les blocages, ou les temps de réponse
excessifs.
6. Tests de sécurité: Les tests de sécurité évaluent la résistance du logiciel aux menaces et aux vulnérabilités.
7. Tests de convivialité: Les tests de convivialité évaluent l'expérience utilisateur et la facilité d'utilisation du logiciel.

MISE EN PLACE D'UN PROJET INFORMATIQUE (ÉTAPES/MODÈLES)

Chaque logiciel est un ouvrage unique, il est construit une seule fois et possède son propre éventail de fonctions et de
mécanismes. Différents modèles de cycle de vie existent mais les activités qui s'y rapportent restent les mêmes. Pour cela, on
identifie un certain nombre d'etapes distinctes, notamment:

1. Comprendre les besoins: Tout d'abord, il faut bien comprendre ce que l'on souhaite du système, en prenant en compte les
ressources disponibles et les contraintes. ...
2. Specification: Ensuite, on écrit clairement ce que le logiciel doit faire dans le cahier des charges, en précisant l'architecture
du projet, ses fonctionnalités, les interfaces, comment il gère les données, sa sécurité, et les technologies à utiliser.
3. Mise en place et implémentation: On met en place le système en le développant et en le configurant conformément à la
description établie dans le cahier des charges.
4. Tests et verification: le test unitaire consiste a verifier que chaque unitE, module ou composant correspond a sa
specification, et aussi pour anticiper les erreurs potentiels
5. Mise en production et maintenance: cette phase est la plus longue du cycle de vie, le systeme est installE et mis en service,
la maintenance est la correction des erreurs, ainsi que l'enrichissement des services du systeme au fur et a mesure que de
nouveaux besoins sont decouverts

=> Modèle en cascade: On considère le développement logiciel comme une succession d'étapes réalisées de façon strictement
séquentielle, chaque étape correspond à une activité de base. Pour améliorer le modèle, on a introduit des retours en arrière.

Inconvénients :

L'utilisateur ne découvre l'app qu'en tout dernier lieu.

Il n'intervient pas dans le processus de conception.
Le risque d'augmentation des coûts de correction des erreurs croît avec le temps, ce qui peut entraîner l'abandon du projet.

=> Modèle en V: La représentation du modèle en V tient davantage compte de la réalité. Le processus de développement n'est
pas réduit à un enchaînement de tâches séquentielles, elle montre que :

C'est en phase de spécification que l'on se préoccupe des procédures de qualification.

C'est en phase de conception globale que l'on se préoccupe des procédures d'intégration.
C'est en phase de conception détaillée que l'on prépare les tests unitaires.

Inconvénients :

Il n'intervient pas dans le processus de conception.

Ne valide l'application qu'à la fin lorsque le logiciel complet lui est livré.
La prise de risque est similaire à celle de l'approche en cascade.

=> Maquetage et Prototypage : Le maquetage et le prototypage sont des méthodes permettant de créer des modèles
préliminaires d'un produit logiciel, on distingue 3 types de prototypes
 Maquette ou prototype rapide : Utilisé pour valider les spécifications rapidement.
Prototype expérimental : Teste des parties critiques.
Prototype évolutif : Devient progressivement le produit final. Ces approches sont utiles pour comprendre les défis,
impliquer les utilisateurs et évaluer les risques, mais elles ont des limites, notamment la tentation de construire le produit
final à partir du prototype.

Avantages :

Construire un prototype jetable pour mieux comprendre les points durs (exigences, technologies).
Permet d'impliquer l'utilisateur et d'éclaircir les etapes
Permet d'évaluer des risques et de tester une solution.

Inconvénients :

Le client doit comprendre ce qui est propre au prototype.

Coût mal compris par les managers et les clients.
Tentation de construire à partir du prototype et donc d'utiliser des solutions non optimales.
N'aborde qu'une phase du développement.

=> Modèle en Spirale: Le modèle en spirale est une approche de gestion de projet qui prend en compte l'évaluation continue
des risques tout au long du cycle de développement d'un produit. Le processus de la spirale se divise en quatre phases :

Détermination des objectifs

Analyse des risques : évaluation des alternatives à partir de maquetage et/ou prototypage.
Développement et vérification : un modèle en cascade ou en V peut être utilisé ici.
Revue des résultats.

CONCLUSION: Dans le développement logiciel, chaque étape doit être terminée avant la suivante et nécessite un document
pour démarrer la prochaine étape.

CHOIX DE CYCLE DE VIE DE DEVELOPPEMENT + ARGUMENTS

CONTEXT => Pour le développement d'un logiciel de [sujet], en tant qu'entreprise de génie logiciel spécialisée en objet, nous
avons la responsabilité de choisir le cycle de vie de développement le plus approprié pour ce projet. Après avoir examiné les
différentes options, je propose d'adopter le Modèle en Spirale pour les raisons suivantes:

REP 0 -> [INTRO]

REP 1 -> [LES 5 ETAPES/MODELES DE LA MISE EN PLACE D'UN PROJET INFORMATIQUE]

REP 2 -> [EXPLICATION DU MODELE EN SPIRALE]

En conclusion, le modèle en spirale semble être la meilleure option pour le développement du logiciel de [sujet], car il combine
les avantages des modèles en cascade, en V et du maquettage/prototypage tout en gérant efficacement les risques.

THEMES PROPOSES PAR LE GL POUR ATTEINDRE CES OBJECTIFS

Le génie logiciel propose plusieurs thèmes et pratiques pour atteindre ses objectifs, notamment :

Correspondance aux besoins clients : Assurer que le logiciel développé répond précisément aux besoins réels du client
Respect des délais et des coûts : Gérer les projets de manière à respecter les échéances et les budgets alloués.
 Qualité du logiciel : Viser la qualité sous différents aspects, tels que la capacité fonctionnelle, la securité, la facilité
d'utilisation, la performance, la maintenabilité et la portabilité.
Méthodes de développement et cycle de vie du logiciel : Utiliser des méthodes structurées, y compris des modèles et des
démarches.
Outils de développement : Utiliser des outils informatiques tels que AGL (Ateliers de Génie Logiciel) pour aider les
développeurs à gérer les projets, générer du code, et assurer la qualité.
Critères de qualité : Établir des critères de qualité pour évaluer le logiciel
Documentation : Produire une documentation complète comme la documentation contractuelle, de conception, de
maintenance, et guide d'utilisation pour les utilisateurs finaux

CAHIER DES CHARGES (CDC)

Le Cahier des Charges du Logiciel (CDC) est un document important pour dire ce que le logiciel doit faire. Ce n'est pas pour
dire comment le faire, mais seulement pour expliquer les choses qu'il doit pouvoir faire. Le CDC est divisé en parties différentes :

1- Introduction Ici, on explique pourquoi le logiciel est nécessaire, quelles sont les grandes choses qu'il doit faire, et comment le
document est organisé.

2- Matériel Si le logiciel a besoin de matériel spécial, on dit quel matériel et comment il doit être.

3- Modèle conceptuel Cette partie montre comment les grandes fonctions du logiciel sont connectées. On utilise des dessins
pour expliquer.

4- Besoins fonctionnels Ici, on explique en mots simples ce que le logiciel doit faire pour l'utilisateur. On peut aussi donner des
références à des détails plus techniques.

5- Besoins en matière de base de données On dit comment les informations seront stockées et reliées dans le logiciel.

6- Besoins non fonctionnels Cette partie parle des règles spéciales que le logiciel doit suivre, comme des limites de temps ou de
sécurité.

7- Evolution du système (information destinée à la maintenance) C'est pour expliquer comment le logiciel peut changer à
l'avenir.

8- Glossaire Un glossaire est un mini-dictionnaire pour les mots techniques.

9- Index L'index aide à trouver des choses dans le document plus facilement. Il y a différents types d'index.