Partie 1 : Ingénierie logicielle personnelle

Chapitre 1 : Métaphores du développement logiciel
1.1 Qu'est-ce qu'un logiciel ?
1.1.1 Les logiciels ne sont pas des produits de consommation courante.
1.1.2 Les logiciels ne s'usent jamais, quelle que soit la fréquence d'utilisation.
1.1.3 La plupart des logiciels sont des produits personnalisés.
1.1.4 Le logiciel doit être facilement mis à jour.
1.1.5 Un logiciel n'existe pas indépendamment.
1.2 Comparaison avec d'autres domaines professionnels
1.2.1 Le programmeur de l'artiste
1.2.2 Le programmeur comme architecte
1.2.3 Programmeur en tant qu'ingénieur
1.2.4 Les programmeurs en tant qu'artisans techniques
1.2.5 Êtes-vous plutôt artiste, architecte, ingénieur ou artisan ?
1.3 Génie logiciel
1.3.1 Définition formelle du génie logiciel
1.3.2 Taille du projet
1.3.3 Comment le génie logiciel échoue-t-il ?
1.4 Savoir-faire logiciel
1.4.1 Éducation
1.4.2 Formation en apprentissage
1.4.3 Vagabond logiciel
1.4.4 Un artisan qualifié ayant atteint le niveau de maître
1.4.5 Comment l'artisanat logiciel peut-il échouer ?
1.5 Comment écrire du code de qualité
1.6 Références

Chapitre 2 Productivité
2.1 Qu'est-ce que la productivité ?
2.2 Comparaison de la productivité des programmeurs et de la productivité des équipes
2.3 Heures du personnel et heures de travail effectives
2.4 Complexité conceptuelle et pratique du projet
2.5 Prévisions de productivité
2.6 Indicateurs de mesure de la productivité et leur nécessité
2.6.1 Métriques de taille des fichiers exécutables
2.6.2 Métriques de mesure des instructions machine
2.6.3 Métriques des lignes de code
2.6.4 Métrique du nombre d'instructions
2.6.5 Méthode d'analyse des points de fonction
2.6.6 Métrique de complexité cyclomatique de McCabe
2.6.7 Autres indicateurs
2.6.8 Problèmes liés aux indicateurs de mesure
2.7 À propos des résultats de l'enquête selon lesquels les programmeurs écrivent dix lignes de code par jour
2.8 Estimation de la période de développement
2.8.1 Estimation de la durée de développement des petits projets
2.8.2 Estimation de la période de développement des projets de moyenne et grande envergure
2.8.3 Problèmes liés à l'estimation des périodes de développement
2.9 Gestion de projet en situation de crise
2.10 Le secret pour améliorer la productivité
2.10.1 Sélection rigoureuse des outils de développement logiciel
2.10.2 Gestion des frais généraux
2.10.3 Définir des objectifs et des étapes clés clairs
2.10.4 Se motiver
2.10.5 Maintenir sa concentration et éliminer les distractions
2.10.6 Lorsque vous vous ennuyez, essayez de faire autre chose.
2.10.7 Créer un environnement propice au développement personnel.
2.10.8 Demandez de l'aide lorsque vous en avez besoin
2.10.9 Revitaliser l'ambiance de l'équipe
2.11 Références

Chapitre 3 Modèle de développement logiciel
3.1 Cycle de vie du développement logiciel
3.2 Modèle de développement logiciel
3.2.1 Modèle abrégé
3.2.2 Modèle en cascade
Modèle 3.2.3 V
3.2.4 Modèle itératif
3.2.5 Modèle en spirale
3.2.6 Modèle de développement rapide d'applications
3.2.7 Modèle incrémental
3.3 Méthodologie de développement logiciel
3.3.1 Méthodologies traditionnelles (prédictives)
3.3.2 Méthodologie adaptative
3.3.3 Méthodologie Agile
3.3.4 Programmation extrême
Guide du design simple
3.3.5 Scrum
3.3.6 Développement axé sur les objectifs
3.4 Modèles et méthodologies de développement logiciel pour les excellents programmeurs
3.5 Références

Partie 2 UML

Chapitre 4 : Vue d’ensemble d’UML et des cas d’utilisation
4.1 Norme UML
4.2 Modèle de cas d'utilisation UML
4.2.1 Éléments d'un diagramme de cas d'utilisation
4.2.2 Package de cas d'utilisation
4.2.3 Inclusion des cas d'utilisation
4.2.4 Généralisation des cas d'utilisation
4.2.5 Extensions de cas d'utilisation
4.2.6 Description du cas d'utilisation
4.2.7 Scénarios d'utilisation
4.3 Diagramme de limites du système UML
4.4 Domaines au-delà des cas d'utilisation
4.5 Références

Chapitre 5 Diagrammes d'activité UML
5.1 Symboles d'état d'activité UML
5.1.1 État initial et état final
5.1.2 Activités
5.1.3 Statut
5.1.4 Transition
5.1.5 Expressions conditionnelles
5.1.6 Point de fusion
5.1.7 Événements et déclencheurs
5.1.8 Synchronisation Fork et Join
5.1.9 Indicatif d'appel
5.1.10 Cloisons
5.1.11 Notes et annotations
Connecteur 5.1.12
5.1.13 Autres symboles de diagramme d'activité
5.2 Extension des diagrammes d'activité UML
5.3 Références

Chapitre 6 Diagrammes de classes UML
6.1 Analyse et conception orientées objet en UML
6.2 Visibilité dans les diagrammes de classes
6.2.1 Visibilité des cours publics
6.2.2 Visibilité des cours privés
6.2.3 Visibilité des catégories protégées
6.2.4 Visibilité des classes de paquets
6.2.5 Ajout de types de visibilité
6.3 Éléments d'attribut de classe
6.3.1 Visibilité des propriétés
6.3.2 Valeurs dérivées des propriétés
6.3.3 Noms des attributs
6.3.4 Types de données des attributs
6.3.5 Types de données d'opération (valeurs de retour)
6.3.6 Expression de la pluralité des attributs
6.3.7 Valeurs de propriété par défaut
6.3.8 Chaînes de propriétés
6.3.9 Grammaire des attributs
6.4 Éléments d'opération de classe
6.5 Pertinence des classes UML
6.5.1 Dépendances de classes
6.5.2 Associations de classes
6.5.3 Relation entre ensembles de classes
6.5.4 Relations de composition des classes
6.5.5 Caractéristiques de la pertinence de la classe
6.5.6 Relations d'héritage de classe
6.6 Objets
6.7 Références

Chapitre 7 Diagrammes d'interaction UML
7.1 Diagramme de séquence
7.1.1 Ligne de secours
7.1.2 Types de messages
7.1.3 Étiquettes des messages
7.1.4 Numéro de message
7.1.5 Conditions de protection
7.1.6 Exécution répétée
7.1.7 Retards importants et contraintes de temps
7.1.8 Objets externes
7.1.9 Barre d'activation
7.1.10 Branchement
7.1.11 Flux alternatif
7.1.12 Création et suppression d'objets
7.1.13 Fragments de séquence
7.2 Schéma de communication
7.3 Références

Chapitre 8 : Autres diagrammes UML
8.1 Schéma des composants
8.2 Schéma de l'emballage
8.3 Diagramme de déploiement
8.4 Diagramme de structure de liaison
8.5 Diagramme d'état
8.6 Intérêt croissant pour UML
8.7 Références

Documentation de la partie 3

Chapitre 9 Documentation système
9.1 Types de documentation système
9.2 Fonctionnalité de suivi de l'historique des modifications
9.2.1 Application de la traçabilité à la documentation pour les développeurs
9.2.2 Format des balises
9.2.3 Matrice de traçabilité de l'historique des exigences
9.3 Vérification, examen et confirmation
9.4 Réduire les coûts de développement grâce à la documentation
9.4.1 Réduction des coûts grâce à la validation des besoins des utilisateurs
9.4.2 Réduction des coûts grâce à l'examen de la conformité aux exigences
9.5 Références

Chapitre 10 Exigences de documentation
10.1 Source et traçabilité des exigences
10.1.1 Format des exigences recommandées
10.1.2 Caractéristiques des exigences excellentes
10.2 Objectifs de conception
10.3 Spécifications des exigences système
10.4 Spécifications des exigences logicielles
10.4.1 Introduction
10.4.2 Description générale
10.4.3 Exigences détaillées
10.4.4 Informations d'assistance diverses
10.4.5 Exemple de spécification des exigences logicielles
10.5 Exigences en matière de rédaction
10.6 Cas d'utilisation
10.6.1 Activer/Désactiver le mode débogage
10.6.2 Activation/Désactivation de l'Ethernet
10.6.3 Activation/Désactivation RS-232
10.6.4 Activer/Désactiver le mode test
10.6.5 Activation/Désactivation USB
10.6.6 Lecture des commutateurs DIP
10.7 Rédaction des cas d'utilisation en tant qu'exigences logicielles DAQ
10.8 Rédaction des exigences logicielles DAQ à partir du SRS
Mises à jour 10.9 RTM utilisant les informations relatives aux exigences
10.9.1 Vérification des exigences par examen
10.9.2 Vérification des exigences par des tests
10.10 Références

Chapitre 11 : Documentation des spécifications de conception logicielle
11.1 Norme IEEE 1016-1998 vs Norme IEEE 1016-2009
11.2 Modèle conceptuel IEEE 1016-2009
11.2.1 Considérations relatives à la conception et participants aux travaux de conception
11.2.2 Points de vue et éléments de conception
11.2.3 Vue de conception, superposition de conception et justification de conception
11.2.4 Modèle conceptuel de la norme IEEE 1016-2009
11.3 Contenu requis SDD
11.3.1 Informations d'identification SDD
11.3.2 Participants à la conception et considérations relatives à la conception
11.3.3 Vue de conception, point de vue, superposition et Rational
11.4 Traçabilité et balises SDD
11.5 Proposition de présentation générale du SDD
11.6 Exemple d'écriture de SDD
11.7 Mises à jour RTM utilisant les informations de conception
11.8 Rédaction des documents de conception logicielle
11.9 Références

Chapitre 12 : Documenter les tests logiciels
12.1 Documentation des tests logiciels selon la norme Std 829
12.1.1 Assistance au processus de test
12.1.2 Niveau d'importance et évaluation des risques
12.1.3 Niveaux de test de développement logiciel
12.2 Plan de test
12.2.1 Plan directeur des tests
12.2.2 Plan de test de niveau
12.2.3 Documentation de la conception des tests de niveau
12.3 Documentation de la liste d'examen des logiciels
12.3.1 Exemple de rédaction d'un plan de document SRL
12.3.2 Exemple de rédaction d'une SRL
12.3.3 Ajout d'éléments SRL à la RTM
12.4 Documentation des cas de test logiciel
12.4.1 Introduction au document STC
12.4.2 Détails
12.4.3 Légende
12.4.4 Exemple de rédaction de cas de test logiciel
Mise à jour RTM 12.4.5 utilisant les informations STC
12.5 Documentation des procédures de test logiciel
12.5.1 Procédures de test logiciel selon la norme IEEE 829-2009
12.5.2 Extension de la présentation générale du document STP
12.5.3 Introduction au document STP
12.5.4 Procédure de test
12.5.5 Légende
12.5.6 Index
12.5.7 Exemple d'écriture STP
12.5.8 Mise à jour du RTM avec les informations STP
Journal de test de niveau 12.6
12.6.1 Introduction au document de suivi des tests de niveau
12.6.2 Détails
12.6.3 Glossaire des termes
12.6.4 Quelques commentaires sur le journal de test
12.7 Rapport de problème
12.7.1 Introduction au rapport de problème
12.7.2 Détails
12.7.3 Quelques commentaires sur le rapport de problème
Rapport de test 12.8
12.8.1 Aperçu du rapport de test principal
Rapport de test de niveau 12.8.2
12.9 De quelle documentation développeur avez-vous réellement besoin ?
12.10 Références

Critique : Concevoir du code de qualité

* Ce que ce livre aborde

- La nécessité d'améliorer l'efficacité du travail grâce à un modèle de développement logiciel artisanal
- Comment utiliser la fonction de suivi pour assurer la cohérence entre les documents de votre travail de documentation.
- Comment rédiger des exigences UML à partir d'une analyse des cas d'utilisation
- Méthode de gestion de la qualité logicielle basée sur les normes de documentation IEEE

* Public cible de ce livre

Il est supposé que vous comprenez un ou plusieurs langages de programmation procéduraux ou orientés objet tels que C, C++, C#, Swift, Pascal, BASIC, Java ou assembleur.
Elle suppose également que les problèmes qui surviennent lors de la conception et de la mise en œuvre de solutions logicielles peuvent être concrétisés.
Si vous avez fait des études en informatique dans un institut technique ou une université, ou si vous avez suivi au moins un semestre de cours dans ce domaine, vous ne devriez avoir aucune difficulté à lire ceci.
Il est supposé que le lecteur possède une compréhension de base de l'organisation des ordinateurs et de la représentation des données.


Note de l'auteur

Avant que le concept de génie logiciel ne s'établisse, le développement logiciel était considéré comme une pratique secrète, exercée par un petit nombre d'artisans du logiciel possédant des compétences et des réalisations difficiles à expliquer.
À l'époque, le succès d'un projet logiciel reposait sur un ou deux programmeurs principaux exceptionnels, et non sur l'équipe.
Le modèle conceptuel d'ingénierie logicielle introduit ultérieurement a permis d'accroître la productivité en assurant des compétences équilibrées au sein de l'équipe de développement et en réduisant la dépendance à l'égard d'un petit nombre de développeurs exceptionnels.


Le modèle conceptuel du génie logiciel a connu un certain succès.
Les programmeurs travaillant en équipe peuvent mener à bien des projets de grande envergure que des organisations plus petites n'auraient jamais pu réaliser par le passé, mais la qualité de certains éléments clés est en deçà des attentes.
Le génie logiciel met l'accent sur l'augmentation de la productivité grâce au travail en équipe, mais sacrifie en même temps la créativité, les compétences techniques et le potentiel de croissance des programmeurs individuels.
Bien que le génie logiciel puisse améliorer les compétences d'un programmeur, il peut aussi réduire ses chances de devenir un excellent programmeur ou limiter ses capacités.
Nous souhaitons tous que les programmeurs atteignent leur plein potentiel, mais les règles rigides du génie logiciel peuvent entrer en conflit avec leur volonté d'atteindre ce plein potentiel.

La série « Great Code » est un modeste effort pour restaurer la créativité, les prouesses techniques et le potentiel de croissance des programmeurs à l'ère du génie logiciel.
Ce livre aborde ce sujet sous l'appellation « ingénierie logicielle personnelle » et présente des méthodes permettant aux programmeurs individuels d'améliorer la qualité de leur code.
Il présente notamment des méthodes pour écrire du « code de qualité » (un code facile à maintenir, à améliorer, à tester et à déboguer, à documenter, à déployer et à supprimer).
Un code de qualité peut aussi être un code exempt de « bricolages », c'est-à-dire de défauts résultant de décisions irrationnelles ou d'une mauvaise planification de la part des ingénieurs ou de la direction.
Un bon code est, en un mot, un code dont son auteur peut être fier.

Note du traducteur

Ce livre est le troisième ouvrage de Randall Hyde sur l'écriture de code de qualité. Il a débuté sa carrière comme développeur de logiciels (pour le contrôle des réacteurs nucléaires) il y a plus de 40 ans et peut être considéré comme une compilation de méthodologies, de stratégies, de théories pratiques et de systèmes qui ont existé dans l'industrie du développement logiciel au cours des 40 dernières années.
Dans les deux premiers volumes de la série Great Code, l'auteur a présenté des méthodes efficaces de communication avec le matériel et des méthodes de réflexion à bas niveau et de programmation à haut niveau. Dans le troisième volume, il explique le logiciel comme un objectif d'ingénierie.


Ce livre explique systématiquement le développement logiciel, du modèle de développement logiciel aux tests et à la documentation, en utilisant des exemples et un déroulement cohérents, de sorte qu'il peut expliquer les parties qui ne pourraient être expliquées que par l'empathie et la sincérité, abordant le développement logiciel d'un point de vue d'ingénierie plutôt que comme un produit de l'écriture.


Les sujets de développement populaires à l'époque de l'auteur Randall Hyde (comme le contrôle des réacteurs nucléaires) ont évolué vers des domaines tels que le cloud computing, l'intelligence artificielle, l'informatique quantique et la blockchain. Les approches et méthodologies de développement se sont également spécialisées, voire ont complètement changé de contexte dans certains cas.
Mais le désir de créer de meilleurs logiciels, d'excellents logiciels, est quelque chose que tous les développeurs ont à l'esprit.


Je pense que ce livre serait une bonne lecture pour quelqu'un qui a commencé à travailler dans le développement logiciel par passion et qui souhaite soudainement avoir une vue d'ensemble de l'industrie du logiciel, se familiariser avec le discours sur le développement qui existe depuis plusieurs décennies et planifier la gestion de sa carrière de développeur pour les prochaines années.
Pour ces lecteurs, l'auteur explique méticuleusement non seulement la méthodologie de développement logiciel, mais aussi comment gérer efficacement une équipe de projet, pourquoi les projets s'écartent souvent de leurs objectifs et comment effectuer les tâches quotidiennes.
Il est également recommandé aux développeurs qui réfléchissent à la manière de faire un meilleur travail que le projet qu'ils ont réalisé l'année dernière.