Développement de systèmes et nouvelles technologies

Le modèle en cascade fait progresser les phases comme une chute d'eau, de l'amont vers l'aval, en validant les livrables de chaque phase avant de passer à la suivante. Construire par courtes itérations relève du développement agile, affiner les besoins par un prototype relève du modèle de prototypage, et combiner des services existants décrit un mashup.

Le modèle de prototypage vise à réaliser tôt un prototype et à le faire manipuler par les utilisateurs, afin de lever dès le début du projet les ambiguïtés des besoins et les écarts de compréhension entre le donneur d'ordre et le développeur. Il ne vise ni la réduction du nombre de lignes de code, ni la suppression des tests, ni la suppression de la maintenance.

Le développement agile consiste à accumuler, à chaque itération courte, un logiciel qui fonctionne, en s'adaptant avec souplesse aux changements de spécifications ; Scrum et l'XP en sont des méthodes représentatives. Fixer toutes les exigences avant de développer en bloc, achever toute la documentation avant de commencer, ou ne faire intervenir les utilisateurs qu'à la fin, sont des façons de procéder proches du modèle en cascade, non des caractéristiques agiles.

Le sprint est une courte période fixe, unité du développement dans Scrum, au cours de laquelle on répète le cycle planification, développement, production d'un logiciel fonctionnel et rétrospective. Ce n'est ni la phase de définition des besoins, ni la période de recette finale, ni une période consacrée uniquement à la correction d'erreurs.

Le modèle en cascade progresse selon l'hypothèse qu'on ne revient pas en arrière ; si une erreur de besoins ou de conception est découverte tardivement, lors des tests, le coût de retour en arrière vers l'amont pour la corriger est très élevé. Comme chaque phase produit un cahier des charges ou un document de conception, le suivi de l'avancement est au contraire un point fort, et le modèle convient aux développements de grande envergure. Il ne rend pas non plus impossible la documentation des besoins.

Le modèle incrémental découpe le système en unités fonctionnelles et accumule le développement et la mise en production par étapes, comme les modèles itératifs, avec l'avantage de pouvoir utiliser certaines fonctions dès une phase précoce. Le modèle en cascade développe l'ensemble en un bloc dans un ordre séquentiel, la méthode d'analyse structurée est une méthode d'analyse utilisant des DFD, et le mashup combine des services existants : aucun ne correspond ici.

Le développement suit en principe l'ordre suivant : l'analyse des besoins, qui organise les besoins de l'utilisateur, puis la conception externe portant sur les aspects visibles de l'utilisateur, la conception interne portant sur les modalités internes de réalisation, la programmation et enfin les tests. Un ordre où la conception précède l'analyse des besoins, ou où les tests précèdent la programmation, ne tient pas compte de la dépendance entre les livrables.

La conception externe porte sur les spécifications des écrans, des états imprimés, des interfaces avec d'autres systèmes, et plus généralement sur ce qui est visible de l'utilisateur ou de l'extérieur. La détermination des algorithmes internes ou du mode de stockage physique relève de la conception interne ou de la conception des programmes, et la vérification du fonctionnement d'un module isolé relève du test unitaire.

Le test unitaire est la première étape des tests : il vérifie, module par module, que le fonctionnement est conforme à la conception détaillée. Combiner des modules pour vérifier leurs interfaces relève du test d'intégration, la recette par le donneur d'ordre du test d'acceptation, et la vérification des performances sous forte charge du test de charge ou de performance.

Les tests s'enchaînent des plus petites unités vers les plus grandes : d'abord le test unitaire module par module, puis le test d'intégration qui combine les modules, le test système qui vérifie l'ensemble, et enfin le test d'acceptation mené par le donneur d'ordre et les utilisateurs. Effectuer d'abord la vérification globale ou la recette reviendrait à faire les tests de niveau supérieur alors que des défauts de composants subsistent encore, ce qui n'est pas rationnel.

Le test d'acceptation est l'étape finale par laquelle le donneur d'ordre et les utilisateurs vérifient, du point de vue de l'activité, le système livré et décident de son acceptation. La vérification de la logique interne relève du test unitaire réalisé par le développeur (test en boîte blanche), la vérification sans exécution du programme relève du test statique, et la vérification de la connexion entre modules relève du test d'intégration : rien de tout cela ne décrit le test d'acceptation.

Le test en boîte noire considère l'intérieur du programme comme une « boîte noire » et vérifie uniquement si la relation entre entrée et sortie est conforme aux spécifications. Le test en boîte blanche est une technique attentive à la couverture des branches et des chemins internes, le test statique est une méthode de vérification sans exécution du programme, par exemple par relecture, et le test de régression vérifie qu'une correction n'a pas cassé d'autres fonctionnalités.

Vérifier si le système résiste à une charge élevée, comme de nombreux accès simultanés ou un grand volume de données, relève du test de charge, réalisé au stade du test système avec le test de performance qui vérifie par exemple le temps de réponse. Le test unitaire vérifie chaque module, le test statique est une vérification sans exécution, et le test en boîte blanche est une technique centrée sur la structure interne.

Le cahier des charges fonctionnel formalise, à l'issue de l'analyse des besoins, les fonctions, performances et contraintes que le système doit réaliser, et fait l'objet d'un accord entre le donneur d'ordre et le développeur ; il sert ensuite de référence pour la conception, les tests et la recette. Le manuel d'utilisation s'adresse aux utilisateurs, le rapport de résultats du test unitaire consigne les résultats des tests, et le schéma d'architecture réseau est un document de conception présentant la configuration : aucun ne constitue le document de référence de l'accord.

Le WBS décompose de façon hiérarchique et structurée les livrables du projet et les tâches nécessaires pour les produire, ce qui évite les oublis de tâches et clarifie les unités d'estimation et d'attribution des responsabilités. Le diagramme à barres horizontales représentant le calendrier est le diagramme de Gantt, la gestion par la valeur acquise est l'EVM (gestion de la valeur acquise), et l'évaluation des risques relève de l'analyse des risques.

Le diagramme de Gantt représente par des barres horizontales le début et la fin prévus de chaque tâche ; il est largement utilisé pour visualiser le planning et l'avancement. Le diagramme de flux de données représente la circulation des données, le diagramme entité-association les relations entre entités, et le diagramme de cas d'utilisation les interactions entre le système et les utilisateurs : ce ne sont pas des diagrammes de gestion du calendrier.

Il existe deux chemins : A→B→D→F (3+5+4+2=14 jours) et A→C→E→F (3+4+6+2=15 jours). F devant attendre l'achèvement des deux chemins, la durée minimale globale correspond au plus long, soit 15 jours. Ce chemin le plus long A→C→E→F est le chemin critique. 14 jours ne correspond qu'au chemin A→B→D→F, tandis que 12 et 13 jours ne correspondent au total d'aucun chemin.

Il existe trois chemins : A→B→D→F (2+4+3+1=10 jours), A→C→D→F (2+6+3+1=12 jours) et A→C→E→F (2+6+4+1=13 jours). Le plus long, A→C→E→F=13 jours, constitue le chemin critique. 10 et 12 jours correspondent aux autres chemins, et 14 jours ne correspond à aucun chemin. Tout retard sur les tâches du chemin critique (A, C, E, F) se répercute directement sur l'ensemble du projet.

La méthode des points de fonction estime la taille d'un logiciel en attribuant des points au nombre et à la complexité des fonctions — entrées, sorties, consultations, fichiers internes, etc. — et permet une estimation dès le début du développement, indépendamment du nombre de lignes de code. Le LOC est une autre mesure d'estimation fondée sur le nombre de lignes, la méthode Delphi fait converger l'opinion d'experts par des questionnaires répétés, et la méthode KJ est une technique de créativité qui organise des informations en les regroupant sur des fiches.

La gestion des risques se conduit dans l'ordre suivant : d'abord l'identification des risques, qui les recense, puis l'analyse des risques (qualitative et quantitative) qui évalue leur probabilité et leur impact, le plan de réponse aux risques qui détermine les mesures, et enfin la surveillance et la maîtrise des risques qui suivent la situation en cours d'exécution. Réaliser le plan de réponse ou la surveillance avant l'identification ne tient pas, puisque les risques concernés ne sont pas encore déterminés.

Une modification de spécifications doit suivre la procédure de gestion des changements : on évalue l'impact sur le calendrier, le coût et la qualité, puis le comité de contrôle des changements (CCB) décide de l'approuver ou de la rejeter. Une acceptation inconditionnelle expose à des retards et à une baisse de qualité, un refus systématique fait perdre des changements pourtant nécessaires, et laisser un développeur modifier le programme sur-le-champ crée des incohérences entre la configuration et la documentation, avec une perte de maîtrise.

Les parties prenantes désignent l'ensemble des personnes et organisations — donneur d'ordre, utilisateurs, développeurs, direction, etc. — ayant un intérêt dans le résultat du projet ; identifier et concilier leurs attentes est une activité importante de la gestion de projet. Le diagramme du calendrier correspond au diagramme de Gantt, la décomposition hiérarchique des travaux au WBS, et la liste des risques au registre des risques.

Le SLA est un accord conclu entre le prestataire et l'utilisateur d'un service sur le niveau de qualité de service — taux de disponibilité, délai de rétablissement en cas d'incident, plages horaires de support, etc. — et sert de référence pour évaluer le service d'exploitation. La protection du droit d'auteur relève du contrat de licence, la structure de décomposition des tâches du WBS, et la location de matériel du contrat de crédit-bail : aucun ne correspond au SLA.

L'ITIL (Information Technology Infrastructure Library) est un ensemble de documents formalisant les meilleures pratiques de gestion de l'exploitation des services informatiques ; il est largement utilisé comme cadre de gestion des services, couvrant par exemple la gestion des incidents, la gestion des changements et le centre de services. Une norme de langage de programmation, une théorie de normalisation ou une norme de réseau sans fil relèvent toutes de domaines différents.

Le taux de disponibilité se calcule par MTBF÷(MTBF+MTTR). 570÷(570+30)=570÷600=0,95. Le MTBF est la durée moyenne de fonctionnement entre deux pannes, et le MTTR la durée moyenne nécessaire à la réparation. 0,90 et 0,98 ne correspondent à aucune inversion du numérateur ou du dénominateur, et 0,93 ne correspond pas non plus au calcul.

La gestion de la capacité anticipe l'évolution future du volume d'utilisation — volume de données, nombre d'accès, etc. — et assure ou renforce de façon planifiée la capacité des serveurs, du stockage et du réseau, afin de prévenir toute dégradation des performances ou insuffisance de capacité. Le dispositif d'alerte en cas d'incident relève de la gestion des incidents et de la réponse d'urgence, la gestion des mots de passe de la gestion des utilisateurs, et le suivi du nombre de licences de la gestion des ressources logicielles.

La virtualisation de serveurs, au moyen d'un logiciel de virtualisation, fait fonctionner plusieurs machines virtuelles sur un seul serveur physique, ce qui améliore l'efficacité d'utilisation des ressources par mutualisation des serveurs et apporte de la souplesse pour les changements de configuration ou la reprise après incident. La répartition physique sur plusieurs sites ou la réduction de la taille des boîtiers relèvent du matériel, et la conservation sur papier n'a aucun rapport avec la virtualisation.

Le SaaS (Software as a Service) fournit l'application elle-même comme service par le réseau, ce qui permet à l'utilisateur de s'en servir sans avoir à installer de logiciel. L'IaaS fournit une infrastructure telle que des serveurs, le PaaS fournit jusqu'à l'environnement d'exécution des applications, tandis que le mode sur site consiste à exploiter des équipements possédés en propre au sein de l'organisation, et n'est pas une forme de fourniture en nuage.

La Société 5.0 est un projet de société visant, en collectant dans l'espace cybernétique les données du monde réel — notamment via l'IoT — pour les analyser, puis en restituant les résultats dans le monde réel, à concilier développement économique et résolution des enjeux sociaux grâce à une fusion poussée entre l'espace cybernétique et l'espace physique. La technologie qui superpose des informations à la réalité est la réalité augmentée (RA), la répartition des calculs relève du traitement distribué, et le corpus de connaissances de gestion de projet est le PMBOK.

L'apprentissage supervisé entraîne, à partir de données étiquetées avec la bonne réponse, un modèle à prédire cette réponse à partir de l'entrée ; il est utilisé par exemple pour la classification d'images ou la prédiction de valeurs numériques. Découvrir soi-même une structure ou un regroupement des données sans fournir de bonne réponse relève de l'apprentissage non supervisé. La formation des utilisateurs n'est pas de l'apprentissage automatique, et la génération aléatoire de sortie par des nombres aléatoires n'a pas de rapport avec l'apprentissage.