1CHAPITRE 1:Conception de logiciel

1 Introduction

La conception de logiciel met en ?uvre tout un ensemble d'activités qui à partir d'une demande d'informatisation d'un processus (demande qui peut aller de la simple question orale jusqu'au cahier des charges complet) permettent la conception, l'écriture et la mise au point d'un logiciel (et donc de programmes informatiques) jusqu'à sa livraison au demandeur.

2. Définitions

1. Un logiciel ou application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique d'assurer une tâche ou une fonction en particulier.

Exemples : logiciel de gestion de la relation client, logiciel de production, logiciel de comptabilité, logiciel de gestion des prêts.

On distingue en général, dans un système informatique, la partie matérielle (l'ordinateur et ses périphériques) et la partie logicielle, immatérielle (les programmes « écrits » sur le disque dur).

Le terme logiciel est souvent employé pour désigner un programme informatique, et inversement, bien qu'un logiciel puisse être composé d'un seul ou d'une suite de programmes.

Ce dernier cas est d'autant plus fréquent que la capacité réduite de calcul de l'ordinateur oblige à une segmentation des tâches en plusieurs modules séparés ; cependant, les énormes capacités des micro-ordinateurs actuels en regard des applications typiques de la bureautique ont permis la réalisation d'applications monolithiques.

Généralement, les programmes sont accompagnés d'un ensemble de données permettant de les faire fonctionner (par exemple, un jeu viendra avec de nombreuses images, animations, sons, etc.).

Pour fonctionner, un logiciel nécessite l'utilisation d'un ordinateur (micro-ordinateur, station de calcul, mainframe, supercalculateur, etc.) sur lequel existe à l'origine un « logiciel-moteur » (système d'exploitation) qui accepte le « logiciel-application ».

Le tout a besoin d'une alimentation électrique.

1.12. Les licences [modifier]

Le droit d'utilisation du logiciel est généralement règlementé par une licence d'utilisation et le droit d'auteur.

Les grandes familles de licences les plus connues sont :

· les licences autour du logiciel libre (free software en anglais) ; · le gratuiciel (freeware) ; · le partagiciel (shareware) ; · d'autres types de licences, telles que les licences monoposte ou multiposte ; · certains logiciels enfin sont internes à des entreprises et leur diffusion est interdite.

1.23. Diverses présentations de logiciels [modifier]

Les programmes peuvent être de différentes formes :

· exécutables : ils peuvent être exécutés directement par l'ordinateur ; · généralement, ils ne peuvent être exécutés que sur un type de machine et de système

d'exploitation particulier (exemple : Microsoft Windows sur un compatible PC) ; · cependant, il existe des exécutables (en bytecode) exécutables sur une variété de plates-

formes (comme ceux du langage Java) ; ils visent en fait l'exécution pour une machine virtuelle, qui est elle-même un logiciel disponible sur les diverses plates-formes.

· fichiers sources : il s'agit généralement d'un texte respectant les règles d'écriture d'un langage de programmation particulier ; à titre indicatif, l'ordre de grandeur de la taille d'un logiciel comme Microsoft Word est d'un million de lignes de code ; · pour un langage compilé : ils doivent être traduits en un exécutable par un

compilateur ; · pour un interpréteur : ils sont exécutés directement à la lecture (par exemple des scripts Perl

ou PHP).

· bibliothèques  : il s'agit de programmes exécutables ou source qui, en eux-mêmes, ne sont pas exécutables directement et n'offrent pas de fonctionnalité à l'utilisateur, mais fournissent des services à d'autres programmes (par exemple, on trouvera des bibliothèques permettant à un programme de charger des animations ou de jouer des sons) ; on trouve en particulier des bibliothèques dynamiques (dll Windows ou so GNU/Linux).

Les données associées au logiciel peuvent également être de différents formats : fichiers classiques, bases de données (relationnelles, hiérarchiques, etc.). Les données du logiciel peuvent être éclatées en un grand nombre de fichiers, ou tout le logiciel peut être rassemblé en un seul fichier ; par exemple, sous Windows, la définition de l'interface utilisateur, le dessin des icônes etc., sont souvent intégrés dans le même fichier que l'application principale.

1.34. Développement de logiciels Article détaillé : Développement de logiciel.

Le développement de logiciel comprend l'ensemble des étapes et processus qui permettent de passer de l'expression d'un besoin informatique à un logiciel fonctionnel et fiable.

Le standard international CMMI recommande, pour un premier niveau de maturité du développement de logiciel, la maîtrise de 7 processus-clés :

· gestion des exigences (spécifications) ; · planification de projet  ; · supervision et suivi de projet  ; · gestion des achats ; · assurance qualité  ; · gestion de configuration ; · mesures et analyses.

Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une petite équipe, ou un ensemble d'équipes coordonnées. Le développement de grands logiciels par de grandes équipes pose de grands problèmes de coordination, en raison de la quantité importante d'informations à communiquer entre les intervenants : documentation, réunions. Pour ces raisons, le développement de logiciels dans un contexte professionnel suit souvent des règles strictes

permettant le travail en groupe et la maintenance du code ; en effet, souvent, les personnes qui doivent opérer des modifications ultérieures dans le code ne sont plus les personnes qui l'ont développé.

Un nouveau modèle de développement tend cependant à se répandre : le bazar (modèle utilisé pour la conception de GNU/Linux)

Un logiciel en version béta (ou béta-test) est un logiciel non finalisé, pour lequel on effectue une série de tests jusqu'à ce qu'une stabilité relative soit atteinte. Les personnes qui cherchent les dernières failles de ces versions de logiciels sont appelés des béta-testeurs.

25. Capability Maturity Model Integration

2.15.1 Historique Dans les années 1980, le DoD (Department of Defense) américain a demandé l'élaboration d'un référentiel de critères lui permettant d'évaluer ses fournisseurs de logiciel. Après une lente maturation, le SEI (Software Engineering Institute) financé par le DoD a présenté en 1991 le CMM (Capability Maturity Model). Ce modèle de référence ne concerne que les bonnes pratiques du génie logiciel. Après un fort engouement pour ce modèle, d'autres modèles similaires ont vu le jour, tels que :

· SE-CMM (pour System Engineering) ; · SA-CMM (pour Software Acquisition) ; · IPD-CMM (pour Integrated Product Development) ; · People CMM pour le management des ressources humaines ; · SS-CMM pour Supplier Sourcing.

Tant et si bien qu’il fallut rebaptiser le CMM « initial » en SW-CMM (pour Software).

En 2001, le SEI a proposé une nouvelle version de son modèle, le CMMI (Capability Maturity Model Integration) qui englobe les bonnes pratiques des autres modèles, sauf la gestion des ressources humaines qui n'est pas encore considérée. La version actuelle du modèle a été réactualisée en 2006.

2.25.2 Descriptif du modèle [modifier]

Dans l'approche étagée (il existe une approche dite "continue"), les bonnes pratiques préconisées par le modèle sont rassemblées en 22 domaines de processus eux-mêmes regroupés en 5 niveaux de maturité :

· Initial : Les facteurs de réussite des projets ne sont pas identifiés, la réussite ne peut donc être répétée (par dérision, ce niveau est aussi nommé héroïque ou chaotique).

· Reproductible : Les projets sont pilotés individuellement et leurs succès sont répétables. · Défini : Les processus de pilotage des projets sont mis en place au niveau de l'organisation

par l'intermédiaire de normes, procédures, outils et méthodes. · Géré : La réussite des projets est quantifiée. Les causes d'écart peuvent être analysées. · Optimisé : La démarche d'optimisation est continue.

2.2.1Le niveau 1 Le niveau 1 Initial est le niveau plancher. Les résultats sont imprévisibles (respect engagements) ; l’atteinte des résultats repose plus sur les hommes, sur leur engagement et bonne volonté, que sur l’application disciplinée de bonnes pratiques définies. Image : ca peut marcher mais en courant dans tous les sens : instabilité.

2.2.2Le niveau 2 Le niveau 2 est orienté Projet. Ce niveau assure que les pratiques basiques de gestion de projet sont toujours mises en ?uvre (gestion des exigences, estimations de charge argumentées, suivi de projet, mesure d’indicateurs, contrôle qualité, …), même dans les contextes difficiles. Les projets respectent généralement leurs engagements. La discipline s’exerce projet par projet. Certains processus sont maîtrisés ; il est possible de les répéter. 7 domaines de processus sont regroupés au niveau de maturité 2

· Gestion des exigences  : Gérer les exigences des produits et des composants produit du projet et identifier les incohérences entre ces exigences et les plans et produits intermédiaires du projet.

· Planification de projet : Établir et maintenir des plans qui définissent les activités du projet.

· Suivi et pilotage de projet : Faire comprendre l'avancement du projet de sorte que des actions correctives appropriées puissent être prises quand l'exécution du projet s’écarte de manière significative du plan.

· Assurance qualité des produits et des processus : Fournir aux équipes et au management une visibilité objective sur les processus mis en ?uvre et les produits intermédiaires associés.

· Mesure et analyse : Développer et maintenir une capacité à mesurer qui réponde aux besoins d'information de gestion.

· Gestion des accords avec les fournisseurs : Gérer l'acquisition de produits fournisseurs pour lesquels il existe un accord formel.

· Gestion de configuration : Établir et maintenir l'intégrité des produits intermédiaires en utilisant l'identification, le contrôle de configuration, l'enregistrement des états de configuration, et les audits de configuration.

2.2.3Le niveau 3 Le niveau 3 est Défini. A ce niveau, l’organisation dispose d’un ensemble de processus standard, qui sont adaptés par chaque projet. Chaque projet capitalise son expérience et permet de bonifier le capital collectif.

2.2.4Le niveau 4 Le niveau 4 est Géré Quantitativement. A ce niveau, les processus clés sont sous contrôle statistique (surveillance d’indicateurs quantitatifs, et actions correctrices si dérives). Élimination des causes spéciales de variation.

· Ex. la capitalisation a permis d’établir la productivité moyenne du processus (taille produite/charge consommée). Le projet se fixe un objectif de productivité en relation et prend des mesures dès qu’il y a des dérives.

2.2.5Le niveau 5 Le niveau 5 est Optimisé. L’organisation est dans une boucle permanente d’amélioration continue. Des analyses causales statistiques menées régulièrement permettent ces améliorations.

2.3Pour aller plus loin Et l'ISO 9001 dans tout ça ?

· Les deux normes concernant les processus de développement logiciel, un article de comparaison peut-être consulté Comparaison entre ISO 9001 et CMMI

CMMI et ISO 15504 alias SPICE

· CMMI, utilisé en mode continu, est un des modèles de processus accepté par la norme ISO 15504

2.3.1Liens externes · SEI - CMMI · mini CMMI-survey , 2007, SQI Hungarian Software Quality Consulting Isntitute Ltd..

Consulté le 07 August  2007

2.3.2Bibliographie Livres sur le CMMI

· Richard Basque, Un itinéraire fléché vers le Capability Maturity Model Intégration - Version 1.2 , éditions DUNOD, 2006.

· Dennis M. Ahern, Comprendre CMMI, une introduction pratique à l'amélioration de processus, traduction : Q-Labs, CEPADUES-EDITIONS, 2006.

2.4

2.56. Bogues Article détaillé : bogue (informatique).

Pour les articles homonymes?, voir Bogue et Bug.

6.1 Définitions

Un bogue ou bug informatique est une anomalie dans un programme informatique l’empêchant de fonctionner correctement. Sa gravité peut aller de bénigne (défauts d’affichage mineurs) à majeure (explosion du vol 501 de la fusée Ariane 5).

Les bogues sont généralement dus à un problème de conception du logiciel ; l'erreur peut parfois être identifiée (et la correction effectuée simplement), mais elle peut aussi bien provenir de la conception même du programme, ce qui nécessite une refonte profonde. Plus rarement, les bogues dans les logiciels peuvent être dus à des erreurs dans les outils de développement utilisés par les programmeurs du logiciel. Enfin, le matériel lui-même peut comporter des bogues, comme ce fut le

cas du bogue de la division du Pentium qui a affecté les premières versions de ce processeur.

Le terme est dérivé du mot anglais bug (bestiole), venant du jargon des ingénieurs de matériel et représentant les erreurs de matériel qui survenaient. Le terme est parfois faussement attribué à Grace Hopper : une anecdote raconte qu'elle aurait découvert qu'un insecte (bug), coincé entre deux contacts du relais qui faisait fonctionner l’appareil, était la raison du mauvais fonctionnement d’un des premiers ordinateurs électromécaniques.

En 1946, Hopper a rejoint la faculté de Harvard au laboratoire où elle a continué son travail sur Harvard Mark II et Harvard Mark III. Elle a attribué une erreur dans Mark II à un papillon nocturne pris dans un relais, créant le terme bug. L’insecte fut enlevé avec soin et placé dans un journal de bord. Cette première anomalie a popularisé l’expression bug ou bogue pour représenter les erreurs dans un programme.[1]

Malgré l’intérêt de l’anecdote ci-dessus, il est reconnu que l’utilisation du mot bug pour décrire les défauts de systèmes mécaniques date d’au moins avant les années 1870. Thomas Edison, entre autres, utilisait le mot dans ses notes. Si l'origine précise du mot est donc incertaine, le rapprochement avec les dysfonctionnements dus à la présence d'un insecte dans le système semble évident.

Le terme anglais bug vient du français « parasite ». En France, c'était le terme utilisé par les électriciens pour les problèmes de lignes utilisé sous la forme « la ligne est parasitée ». Adapté en anglais il est devenu bug puis est revenu en France sous la forme de « bogue » (de châtaigne ?) sous l’égide de la DGLF. Bug reste très largement utilisé.

En France, le terme « bogue » est recommandé par la Délégation générale à la langue française et aux langues de France (DGLF) depuis un arrêté paru au Journal officiel du 30 décembre 1983. Ce mot, qui se veut plus français, n'exprime pas une étymologie. C'est pourquoi peu de gens utilisent la version francisée. À cette époque le genre féminin était préconisé.

Cependant à la fin de la décennie 1990, les dictionnaires tels que le « Nouveau petit Robert » et « Le Petit Larousse illustré » rapportaient l’usage de ce terme au masculin, sans doute sous l’influence québécoise où l’Office québécois de la langue française (OQLF) prônait depuis longtemps l’emploi du genre masculin. Le terme français a été popularisé avec le fameux bogue de l'an 2000 qui, sans avoir entraîné de dysfonctionnement visible majeur, a néanmoins nécessité beaucoup de travaux de transformation des systèmes d'information dans la décennie 1990.

Désormais la DGLF recommande aussi le genre masculin pour ce mot.

2.66.2 Effets Les pessimistes disent qu'il y a des bogues dans tous les programmes informatiques. En revanche, les programmes de qualité contiennent relativement peu d'erreurs et n'empêchent généralement pas le système de continuer ses tâches. Au contraire, les programmes moins bons, quelquefois dits bogués, contiennent beaucoup d’anomalies qui interfèrent souvent avec le fonctionnement du système.

Les bogues ont des effets qui varient grandement. Quelques-uns ont un effet subtil sur le fonctionnement du logiciel et peuvent demeurer inconnus pendant une longue période. D'autres sont plus sévères et peuvent arrêter le logiciel voire bloquer le système.

Dans certains cas, sur les systèmes d’exploitation, les bogues de logiciels peuvent rendre instable le système jusqu’à ce qu’il soit rechargé.

D'autres erreurs de programmation peuvent mener à des failles de sécurité ; le dépassement de tampon est un des bogues les plus communs permettant à un pirate informatique d'exécuter un

nouveau programme sur la machine cible.

Les bogues peuvent avoir des répercussions économiques considérables. Steve McConnell a comptabilisé plusieurs bogues qui ont coûté plus de 100 millions de dollars US.

· Un des cas les plus spectaculaires est celui de la fusée européenne Ariane 5, qui a coûté plus d'un milliard de dollars. Quelques instants après le décollage, elle fut détruite à cause d'une erreur de l'ordinateur de guidage embarqué à bord de l'appareil. Toutefois, dans ce cas, le terme "bogue" est quelque peu impropre : en effet, "l'erreur" a consisté à reprendre à l'identique l'ordinateur et le logiciel utilisé sur Ariane 4 pour la gestion des centrales inertielles de guidage, ordinateur et logiciel qui fonctionnaient parfaitement sur cette fusée. Cependant le reste du système informatique d'Ariane 5 travaillait avec des nombres de 64 bits en virgule flottante alors que ces éléments travaillaient avec des nombres de 16 bits en entier signé. Lors du passage de valeurs d'un système à l'autre est apparu une exception matérielle (plus précisément, un dépassement arithmétique, ou les nombres de 64 bits ont une trop grande valeur pour être représentés en 16 bits, ce qui a fait partir le comportement par défaut de gestion d'erreur : un autotest), ce qui a eu pour effet une déviation de la trajectoire impossible à rectifier depuis le sol.

· La sonde de Vénus Mariner 1 fut perdue d’une façon similaire en 1962. Un trait d’union oublié dans un programme Fortran a coûté plus de 80 millions de dollars. D’après Arthur C. Clarke, ce fut le « plus coûteux trait d’union de l’histoire ».

· Le fameux bogue de l'an 2000, a enrichi les entreprises de conseil en informatique, mais a fait dépenser des fortunes aux entreprises qui ont bien été obligées de modifier la majorité de leurs logiciels, dans la crainte que ceux-ci ne traitent pas correctement les quatre chiffres des années et se retrouvent en 1900 au 1er janvier 2000.

2.76.3 Approche formelle : les méthodes formelles Un bogue est un non-respect de la spécification du système, c’est-à-dire de la définition de ce que le système est censé faire. Une spécification peut être informelle et vague (comme : « le logiciel est un traitement de textes qui ne provoque pas d’erreur à l’exécution »), ou formelle et précise (« tri(t) est une permutation de t telle que tri(t) est ordonnée pour la relation < »), y compris au point d’obtenir des formules mathématiques. Un programme bogué est un programme dont la mise en ? uvre ne vérifie pas la spécification.

On peut se demander s’il existe des méthodes universelles, sans faille et automatiques qu’il suffirait de suivre pour se rendre compte si un programme est bogué ou non. La réponse est non. En effet, si une telle méthode existait, il serait possible de l’automatiser par un ordinateur, c’est-à-dire par un logiciel d’analyse. Cet analyseur devrait opérer sur des programmes à analyser quelconques et devrait, par exemple, répondre à la question suivante : « l’état final du programme peut-il être un état d’erreur à l’exécution, ou est-il forcément un état correct (ou une non-terminaison) ». Or, le théorème de Rice dit qu’on ne peut répondre à cette question sur un système à état infini. Plus généralement, toute question de spécification portant sur l’état final du programme est indécidable, c’est-à-dire qu’un logiciel ou une méthode automatique ne peut y répondre, sauf les questions dont la réponse est toujours vraie ou toujours fausse.

On pourrait objecter que les ordinateurs sont des systèmes à état fini : chaque ordinateur a une quantité finie de mémoire. Cependant, à l’exception de systèmes de très petite taille, il convient, à des fins d’analyse, de considérer les ordinateurs comme des systèmes à mémoire non bornée. En effet, les techniques d’analyse utilisant la finitude de l’état vont toutes, de façon plus ou moins détournée ou optimisée, chercher à énumérer les états du système. Un système à n bits de mémoire a 2n états ; dans un ordinateur personnel actuel, n est de l’ordre de 238. On voit donc que toute tentative d’énumération des états du système est vouée à l’échec.

L’impossibilité de la recherche automatique universelle des bogues est donc un problème d’ordre fondamental, et non une limitation de la technologie actuelle.

2.86.4 Comment en faire ? Comment s’en défaire ? Les bogues sont une conséquence de la nature de la tâche de programmation. Quelques-uns surviennent à cause de simples erreurs d’inattention d’un programmeur écrivant du code source. D’autres bogues sont le résultat d’interférences inattendues entre différentes parties d’un logiciel, voire de comportements imprévus de systèmes extérieurs au logiciel (capteurs défaillants qui retournent des valeurs fantaisistes). Certains, enfin, relèvent de la non-prise en compte des termes exacts des normes définissant les langages et les bibliothèques employées par les programmeurs (cf. exemple). Ces situations arrivent parfois quand les logiciels deviennent trop complexes pour que les programmeurs puissent penser à toutes les possibilités d’interaction entre plusieurs parties d’un programme.

L’industrie du développement logiciel fait de gros efforts pour trouver des méthodes de prévention des erreurs des programmeurs menant à des bogues. Cela inclut :

· Les règles de programmation . On s'impose l’uniformité du style d’écriture (réduit la confusion possible pour les autres développeurs) et l’écriture de documentations détaillées. Typiquement, l’écriture de programmes devra suivre un processus formalisé en étapes successives et documentées.

· Les techniques de programmation. Un bogue peut parfois créer des incohérences dans les données internes d’un programme en fonctionnement. Les programmes peuvent être écrits pour vérifier la cohérence des données internes durant leur exécution. Si un problème est trouvé, le logiciel peut s’arrêter immédiatement pour que le bogue puisse être trouvé et réparé, ou simplement avertir l’utilisateur, essayer de corriger l’incohérence et continuer à fonctionner. De plus, on peut interdire ou du moins sévèrement réglementer l’usage de fonctionnalités de maniement délicat du langage de programmation ou du système.

· Les méthodologies de développement. Il y a plusieurs méthodes pour gérer l’activité des programmeurs afin de minimiser les risques de bogues. Plusieurs de ces techniques relèvent de la spécialité du génie logiciel.

· Le support des langages de programmation. Les langages incluent parfois des fonctionnalités qui aident les programmeurs à traiter les bogues, comme le traitement des exceptions. De plus, plusieurs langages récents ont délibérément exclu des fonctions avancées susceptibles de mener à des bogues. Par exemple, les langages Java et Perl n'offre pas d'accès de bas niveau aux pointeurs, évitant qu’un programme n’accède à une zone de la mémoire par inadvertance.

· Le test. Le logiciel est essayé dans diverses configurations, notamment des configurations difficiles et « extrêmes ». On va aussi tenter de couvrir toutes les fonctionnalités, ou toutes les portions de code du logiciel, ou tous les chemins dans le code (ce dernier critère est en général impossible à atteindre). Cependant, le test ne donne pas d’assurance sur le bon fonctionnement du logiciel dans tous les cas, car il ne tient compte que d’un nombre limité de configurations du système, d’entrées des utilisateurs ou du monde extérieur, etc.

· Les méthodes formelles. Il s’agit ici de parvenir à une preuve, au sens mathématique, de bon fonctionnement du logiciel. La méthode peut fournir plus au moins d’automatisation : les assistants de preuve aident un utilisateur à formuler une preuve mathématique et la vérifient ; le model checking et l’analyse statique par interprétation abstraite sont automatiques ; il existe des gradations intermédiaires. Citons par exemple la Méthode B, utilisée pour la ligne 14 (Meteor) du métro parisien.

Trouver et corriger les bogues, ou déboguer, est une partie majeure de la programmation de logiciels. Maurice Wilkes, pionnier de l’informatique, décrit ses réalisations des années 1940 en disant que l’essentiel du reste de sa vie serait occupé à réparer les erreurs dans ses propres programmes. Alors que les programmes informatiques deviennent de plus en plus complexes, les bogues deviennent plus fréquents et difficiles à corriger. Quelquefois, les programmeurs passent plus de temps et d’efforts à trouver et à corriger les bogues qu’à écrire du nouveau code.

Habituellement, la partie la plus difficile du débogage est de trouver la partie du code responsable de l’erreur. Une fois localisée, la corriger est souvent facile. Des programmes appelés débogueurs existent afin d’aider les programmeurs à trouver les bogues. Toutefois, même avec l’aide d’un débogueur, dénicher un bogue est une tâche souvent très difficile.

Ordinairement, la première étape pour trouver un bogue est de trouver un moyen de le reproduire facilement. Une fois le bogue reproduit, le programmeur peut utiliser le débogueur ou un autre outil pour observer l’exécution du programme dans son contexte habituel, et éventuellement trouver le problème. En revanche, il n’est pas toujours facile de reproduire un bogue. Certains sont causés par des entrées au logiciel qui peuvent être difficiles à reproduire pour le programmeur. D’autres peuvent disparaître quand le programme est lancé dans un débogueur; ceux-ci sont appelés heisenbugs (faisant, par plaisanterie, référence au principe d'incertitude de Heisenberg). Enfin, les bogues des programmes parallèles (composés de plusieurs modules s’exécutant de façon concurrente, par exemple sur plusieurs processeurs) sont souvent difficiles à reproduire s’ils dépendent de l’ordonnancement précis des calculs sur la machine.

2.96.5 Exemple Exemple de code non bogué mais pouvant provoquer une erreur et correction du code pour un fonctionnement détectant les erreurs des autres programmes ou de la machine.

· Le pseudo-code suivant représente une fonction prenant en entrée une adresse mémoire et incrémentant la valeur qui y est stockée.

fonction IncPointeur( pointeur ) *pointeur ++ fin fonction

· Le problème est que dans les systèmes informatiques, il est fréquent que seule une portion de la mémoire soit accessible en écriture et qu’une tentative de le faire dans une zone mémoire protégée ou inexistante, provoque un bogue, une interruption du programme ou au pire, un arrêt du système.

· Dans les systèmes complexes, il est souvent difficile et fastidieux de prévoir tout les cas possibles, c’est pourquoi la tolérance totale n’existe pas. Ceci n’empêche pas de prévoir un maximum de cas pour rendre le programme le plus robuste possible.

fonction IncPointeur( pointeur ) si EstValide( pointeur ) *pointeur ++ retour OK sinon retour ERREUR fin si fin fonction

· Dans le pseudo-code ci-dessus, le programme teste la validité de l’adresse avant d’y accéder, ce qui permet au programme de continuer même si une adresse erronée lui est transmise.

2.106.6 Humour et citations célèbres liées aux bogues · « Ce n’est pas un bogue, c’est une fonctionnalité !» (de l’anglais It’s not a bug, it’s a

feature). - Réponse fréquente des développeurs de logiciels à leurs utilisateurs. · « Tout programme non trivial possède au moins un bogue » (de l’anglais Every non-trivial

program has at least one bug) - Tiré de la loi de Murphy appliquée à l’informatique (Cf. : liens externes ci-dessous)

· « L’erreur est humaine, mais un vrai désastre nécessite un ordinateur » · « Quand un logiciel n'a plus aucun bogue, il est habituellement désuet »

2.116.7 Jeux vidéo Le terme de bogue dans les jeux vidéo a pour signification première une erreur dans le déroulement supposé d'une action. La résultante finale du bogue n'occasionnera pas la même gêne suivant son intensité. Une main d'un joueur traversant un mur dans un jeu de tir subjectif n'aura pas la même nuisance qu'une impossibilité d'accomplir la quête principale d'un jeu de rôles.

L'existence des bogues n'apportent pas que des points négatifs :

· La recherche et la correction de bogues démontrés permettent souvent une correction d'autres bogues inconnus à ce jour et/ou une optimisation du code source, ce qui est très profitable au joueur (jouabilité améliorée) comme au développeur (le support technique régulier d'un jeu est un gage de renommée).

· La popularité exceptionnelle d'un jeu qui connaît toutefois des bogues est souvent initiateur d'une communauté très prolifique capable de corriger ces bogues à l'aide de différents outils. Le jeu le plus symbolique de ce phénomène est certainement Fallout 2.

· Certains bogues peuvent être profitables à des joueurs plus ou moins mal intentionnés. Dans les parties jouable en réseau (sur Internet ou en réseau local), les bogues exploitables sont duaux : soit ils sont source de destruction du fair play (notamment dans les jeux de tir subjectif), soit ils permettent une avancée spectaculaire et consentante entre les joueurs.

· Dans les concours de Speedrun, certains bogues sont très profitables afin de finir un jeu ou une séquence le plus rapidement possible.

Le terme de bogue englobe d'autres notions moins usitées à cause de la popularité du nom de bogue. Il serait judicieux de nommer certaines erreurs par oubli plutôt que par bogue.

2.126.8 types de bogues particuliers · Mandelbug · Schrödinbug · Heisenbug · Bohr bug

2.13Voir aussi [

2.13.1Liens internes · Développement de logiciel · Explorer la catégorie:Développement logiciel · Therac-25

· Débogueur

2.13.2Liens externes [modifier]

· http://www.murphys-laws.com/murphy/murphy-computer.html  : loi de Murphy appliquée à l’informatique.

2.14Note [modifier]

1 ? Le départ de l'intrigue du film Brazil est une illustration de cette anecdote : une insecte provoque un court-circuit dans une machine, transformant le nom Tuttle en Buttle ; ici, le bug met à jour les excès de la bureaucratie.

Des erreurs de conception dans les logiciels peuvent causer des comportements incorrects, souvent appelés bogues. La gravité de ceux-ci peut aller de très mineure (p.ex., apparence légèrement incorrecte d'un élément d'interface graphique), à des évènements catastrophiques (explosion de la fusée Ariane vol 501, irradiation incorrecte de patients par une machine de traitement...) en passant par des pertes plus ou moins grandes de données, et, rarement, par une détérioration du matériel.

Il est difficile, pour des raisons fondamentales, de produire des logiciels sans bogue ; cependant, il existe des mécanismes par lesquels on peut limiter la quantité de bogues, voire les supprimer. Citons d'une part des préceptes d'organisation des équipes de programmation et leur méthodologie, d'autre part les technologies de recherche de bogues dans les logiciels. La recherche en informatique a développé un domaine d'étude, la vérification formelle, dont l'objectif est de certifier la qualité des logiciels et de garantir leur fiabilité. Dans l'ensemble, l'obtention de logiciels complexes peu bogués est coûteuse en hommes et en temps. Plus les anomalies sont détectées tôt au long du développement du logiciel, moins leur correction est coûteuse.

2.157. Ouverture du code source On classe les logiciels d'après la disponibilité du code source et de la licence qui régit la distribution du programme :

· code ouvert  : tout le monde peut lire le code source. Ce terme n'est pas synonyme de logiciel libre ;

· code fermé  : le code source n'est disponible que pour une minorité de personnes ; · logiciel libre  : tout le monde peut étudier, copier, modifier et distribuer des versions

modifiées du logiciel (définition de la free software foundation). Les logiciels libres sont protégés pour la plupart par une licence d'utilisation ; Pour autant cela ne signifie pas que le logiciel est gratuit.

· logiciel propriétaire  : au moins un de ces droits n'est pas rempli pour les utilisateurs. La plupart du temps, acquérir une licence d'utilisation nécessite le paiement d'une certaine somme aux créateurs du logiciel ;

· logiciel commercial  : logiciel destiné à la vente, il peut être libre ou propriétaire.

2.168.Développeurs Voir ou créer l'article : Liste d'éditeurs de logiciels bureautiques.Article détaillé : Liste des éditeurs de jeux vidéo.

2.179. Logiciels critiques

Article détaillé : Profil d'application.

Pour la sécurité globale des systèmes d'information d'une entité, il peut être nécessaire de définir des profils d'application, afin d'identifier les logiciels critiques sur lesquels il est nécessaire de porter une attention particulière du point de vue de la sécurité.

310. Programme informatique

Cet article fait partie de la sérieLangages de programmationLangages à objetsC++ - C# - DDelphi - Eiffel - GroovyJava - Python - RubySimula - SmalltalkVisual Basic - Lisaac - WinDevLangages impératifsAPL - ASP - AssembleurBASIC - C - CobolForth - Fortran - LimboLogo - Pascal - Perl - PHPLangages fonctionnelsHaskell - ML/OCamlLisp/Common LispScheme - XSLTLangages déclaratifsClips - PrologLangages concurrentsAda 95 - ErlangVoir aussiConception - CodageTests - Optimisations

Un programme informatique est une liste d'ordres indiquant à un ordinateur ce qu'il doit faire. Il se présente sous la forme d'une ou plusieurs séquences d'instructions, comportant souvent des données de base, devant être exécutées dans un certain ordre par un processeur ou par processus informatique (cas des systèmes multitâches.

3.1Sommaire[masquer]

· 1 Fonction · 2 Conception

· 2.1 Différences · 3 Voir aussi

· 3.1 Liens internes

3.2Fonction Un ordinateur sans programme ne fait absolument rien, il attend des instructions. En fait, la capacité à suivre un programme enregistré sert même souvent, d'un point de vue historique, à distinguer un ordinateur d'une simple machine à calculer. Avec cette définition, le premier ordinateur est le Manchester Mark I, premier calculateur à programme enregistré.

3.3Conception À l'origine d'un programme, il y a un code source écrit par un programmeur dans un langage de programmation compréhensible par le dit programmeur.

3.3.1Différences Selon le langage utilisé, ce code est ensuite soit :

· Traduit avec un jeu d'instructions spécifique à un processeur par un compilateur, ensuite le programme obtenu peut alors être exécuté directement par l'ordinateur.

· Ou bien est pris en charge par un interpréteur (autre programme), qui décode à la volée les instructions du langage évolué en instructions spécifique au processeur et qui les lui transmet directement pour exécution.

Parfois le langage de programmation se réduit à un ensemble de symboles correspondant aux instructions en code machine. C'est le langage assembleur et, dans ce cas, un programme appelé assembleur est utilisé pour faire la traduction en langage machine.

Le terme « programme informatique » est souvent improprement, utilisé comme synonyme de logiciel, les logiciels actuels étant souvent composés de plusieurs programmes. Les logiciels incluent souvent en plus, des fichiers de ressources contenant des données de toutes sortes, celles-ci ne font pas à proprement parlé partie du programme. Par exemple, Microsoft Internet Explorer, Mozilla Firefox, etc. sont des logiciels plutôt que des programmes, car il sont le fruit de la concaténation de multiples programmes exécutant différentes actions et fonctions.

Un programme simple et souvent abstrait est souvent appelé algorithme. Les programmes d'ordinateur sont aujourd'hui souvent les sujets de la logique et des mathématiques : voir les méthodes formelles, la sémantique des langages de programmation, etc.

3.3.2Liens internes · Logiciel · Programmation informatique · Langage de programmation · Machine de Turing · Forme de Backus-Naur

En règle générale, la conception de logiciel va suivre 3 grandes phases :

· Phase d'analyse (fonctionnelle) ou de conceptionDurant cette phase, on effectue simultanément l'étude des données et l'étude des traitements à effectuer. C'est en général dans cette phase que s'appliquent les techniques de modélisation. Il en découle la description des bases de données éventuelles à créer et les programmes à écrire et la manière dont tout cela va être intégré. · Spécification

· Conception · Définition de l'architecture · Phase de réalisation ou de programmation (écriture et tests des programmes)

· Algorithmique · Codage · Programmation · Contrôle de version · Refactoring · Tests unitaires · Optimisation du code · Phase de livraison

· Intégration · Validation · Documentation du logiciel · Packaging

3.4Sommaire[masquer]

· 1 Modélisation · 1.1 Méthodes de modélisation · 1.2 Méthodes de développement (Gestion de

projet) · 1.3 Langages de modélisation · 1.4 Approche objet · 1.5 Les écueils classiques · 1.6 Liens externes

3.5Modélisation

3.5.1.1Méthodes de modélisation

Une méthode d'analyse et de conception a pour objectif de permettre de formaliser les étapes préliminaires du développement d'un système afin de rendre ce développement plus fidèle aux besoins du client. Parmi les méthodes les plus connues on peut notamment citer Merise, RAD et SADT

article détaillé: méthodes d'analyse et de conception

3.5.1.2Méthodes de développement (Gestion de projet)

· Méthode agile · Extreme programming (XP)

· Dynamic systems development method (DSDM) · Adaptive software development (ASD) · Scrum · Feature driven development · Crystal clear · Merise

3.5.1.3Langages de modélisation

· UML · BON · Merise

3.5.1.4Approche objet

· Orienté objet · Interface de classe

3.5.1.5Les écueils classiques

· la balle en argent · prototypage · le plaqué or · la loi de Brooks

3.5.2Liens externes · Article Le processus unifié un processus de développement logiciel itératif

Catégories   : Programmation informatique • Gestion de projet • Développement logiciel

3.5.2.1.1Affichages

· Article · Discussion · Modifier · Historique

3.5.2.1.2Outils personnels

· Créer un compte ou se connecter

· Aide · Communauté · Modifications récentes · Accueil des nouveaux arrivants · Faire un don

· Boîte à outils

· Pages liées · Suivi des liens · Importer une image ou un son · Pages spéciales · Version imprimable · Adresse de cette version · Citer cet article

3.5.2.1.3Autres langues

· English

Concepts de programmation moderne : Approche objet en c++

Les notes de ce cours sont condensées dans un syllabus à part . Tout étudiant doit en faire sa propre copie. En plus, il est disponible en format électronique sur l'adresse:

http://www.burundisciences.afrikblog.com/

Pour toute information ou difficulté, consultez le professeur :NAHAYO Fulgence, Auteur conceptionneur et réalisateur de ce blog(site).