Le caractéristiques du logiciel

Le caractéristiques du logiciel et l'industrie du logiciel

Systèmes informatiques : • 20 % de matériel • 80 % de logiciel La fabrication du matériel est concentrée sur qq fabricants depuis qq années, • le matériel est relativement fiable, c’est une industrie mature • le marché s’est standardisé. => Les pb liés à l’informatique sont essentiellement des pb de logiciel.

1. Les spécificités du logiciel a) Un objet technique fortement contraint b) Une œuvre d’art c) Un produit immatériel d) Le cycle de production du logiciel Conclusion

2. Typologie du logiciel a) Facteurs sur le logiciel b) Facteurs sur l’utilisation c) Facteurs sur le processus Conclusion

3. La crise du logiciel Utilité Utilisabilité Fiabilité Performances Interopérabilité Portabilité Réutilisabilité Maintenance Coûts Délais La qualité du logiciel

4. CONCLUSION Bilan Capability Maturity Model Solutions Les méthodes Les règles d’or du GL

C. Sibertin-Blanc, Université Toulouse 1 1

1. Les spécificités du logiciel A quels produits peut-on assimiler le logiciel ?

a) Un objet technique fortement contraint Un logiciel est un objet technique qui marche ou pas Il doit être fait avec une grande rigueur et précision Relève des modes de travail du domaine technique, des sciences dures.

b) Une œuvre d’art Concevoir un logiciel est une activité très créatrice Le régime de la propriété :

on n’achète pas un logiciel, mais le droit de l’utiliser, éventuellement pour une durée limitée Absence de garantie Pas de dépôt de brevet.

c) Un produit immatériel Un objet dont l’existence est indépendante de tout support physique, Comparable à un roman, pièce de théâtre, partition de musique, film, théorème De plus, n’a aucun intérêt en tant que tel, seules ses exécutions ont de la valeur • Pas de matière première (=> c’est une industrie de main d’œuvre). • Principe d’identité • Le problème de la mesure • Malléabilité apparente du logiciel mais totale discontinuité de la relation forme –> fonction • Un système complexe


d) Le cycle de production du logiciel : à l'unité Cycle de fabrication d’un produit matériel 1. définition du produit -> prototype 2. conception du procédé de fabrication 3. éventuellement réalisation des équipements nécessaires 4. fabrication –> série Possibilité de tester le prototype et chacune des unités de la série, boucle de rétroaction pour l’amélioration Pour N exemplaires vendus, N x prix de vente =?= coût études + N x coût de fabrication Cycle de fabrication d’un logiciel 1. définition du produit –> logiciel; FIN. définition = production Chaque produit est unique, comme dans les industries de l’information et le Génie Civil =>seule la première copie d’un logiciel a un coût le développement de logiciel est une activité de recherche L’effet tunnel

Lorsque l’on peut tester le logiciel, c’est trop tard pour le modifier car tout est déjà fait !

Conclusion Les propriétés du logiciel sont paradoxales, semblent contradictoires, elles sont conceptuellement encore mal maîtrisées. Le logiciel partage certaines propriétés avec d’autres technologies :

• les œuvres d’art • l’industrie de la communication (récentes, encore peu d’expérience) • le Génie Civile, qui a inspiré les premières méthodes de gestion de projet => Les possibilités de réutiliser les savoir-faire des autres technologies sont (très) limitées. Compte tenu de la structure du cycle de production, il faut faire bien du premier coup

« La qualité du processus de fabrication est garante de la qualité du produit ».


2. Typologie du logiciel

Peut-on capitaliser les savoir-faire d’un projet sur l’autre ? Pour déterminer le degré de ressemblance entre des projets, • trouver des critères, « facteurs de contingence » qui permettent de caractériser chaque

projet, de définir son profil • établir une typologie des logiciels en fonction de la valeur de ces critères Catégories de facteurs : • sur le logiciel lui-même, • sur son utilisation, • sur son procédé de fabrication.

a) Facteurs sur le logiciel

La taille Unité de mesure : le Kilo Instructions Sources Livrées (KISL) La différence entre petits et gros logiciels n’est pas uniquement quantitative, elle est essentiellement qualitative.

La Complexité surtout pour info scientifique Du code :

• la structure des données, • les algorithmes, • les composants, leur répartition dans des fichiers. Des exécutions : • espace mémoire, • nombre d’instructions exécutées (–> temps d'exécution).


PETIT et GRAND PROJETS

CARACTÉRISTIQUE PETIT PROJET GRAND PROJET

taille < 2 KISL > 50 KISL > 500 K

durée 1-2 mois 2 - 5 ans équipe de développement

1 personne 1 ou plusieurs équipes

suivi, gestion du projet

centralisée, informelle répartie, organisée pb de budget et délai, …

compréhension du pb, spécification

immédiate, informelle

difficile, explicite

sources d’erreurs de programmation programmation, fonctionnalités, interface,

utilisateur le développeur nbreux, <>développeurs conséquence des erreurs, validation

faible car elles sont connues, par l’usage

importante soigneuse et complète

déploiement 1 machine en réseau, postes hétérogènes

interface, doc. utilisateur

minimale, voire inutile

explicite, complète

maintenance, doc technique

facile, au coup par coup voire inutile

difficile à organiser, indispensable

gestion des versions

1 seule en cours multiplicité des configurations et des postes de travail

analogie construire un abri de jardin

construire une résidence

Programmation

Génie Logiciel


Les 4 Domaines d’application Calcul Scientifique 5 %

Un programme est fait pour calculer une fonction Domaineargument ------> Domainerésultat

exple : Météo, physique, mathématique, simulation (trajectoire, économique, ...) La première utilisation des ordinateurs, qui a déterminé l’architecture Von Newman. Les algorithmes de calcul sont difficiles. C’est le domaine qui a besoin des plus grosses puissances de calcul. Informatique industrielle 20 %

Un logiciel est fait pour commander un dispositif

Dispositif physique

Opérateur Logiciel de commande

Environnement

état du système

commande

capteurs

effecteurs

Contrainte de temps réel :

La rapidité de l’évolution de l’environnement impose des contraintes fortes sur le temps de réponse du logiciel Pb de concurrence :

- Les entrées sont multiples, les sorties aussi, Il faut les synchroniser. - Système réactif


Systèmes d’Information ou Informatique de gestion 60% Un logiciel est fait pour gérer des informations qui :

• résultent d’une certaine activité, • permettent d’organiser cette activité.

Applications BDUtilisateurs

Problèmes de conception :

• des fonctions que le logiciel doit assurer (traitement des informations), • des Bases de Données (structure et mémorisation des informations), • de l’interface utilisateur (utilisation du logiciel). Peu de pb d’algorithmes. Systèmes Informatiques & Télécom 15% Un logiciel est un outil permettant d’exploiter les possibilités du matériel, il offre des services aux programmes d’application par des API (Application Program Interface).

machinesystème

applications

réseaupériphérique

exple : • système d’exploitation, • environnement de conception, de développement, et d’exécution (AGL), • SGBD, • Réseaux, • Téléphonie.


Taux de procéduralité L’activité à informatiser est-elle bien maîtrisée, les algo sont-ils connus, il y a t-il beaucoup de cas particuliers ? Détermine la difficulté à trouver une solution exple :

• très procédural : info scientifique, comptabilité • peu procédural : aide à la décision, au diagnostique, jeu d’échec : utilisation d'heuristiques

Taux d’innovation L’activité à informatiser est-elle bien connue,

a-t-on de l’expérience dans ce domaine, le pb est-il bien défini ? La difficulté essentielle est de définir le pb à résoudre, et non pas pas de trouver une solution exple : • peu innovant : informatiser telle quelle une activité existante • très innovant : concevoir un outil pour une activité qui ne se pratique pas encore,

les objectifs sont + - connus mais pas les modalités pour les atteindre, Un fort taux d’innovation s’accompagne d’une instabilité des besoins, et donc d’une augmentation du risque d’échec.

non innovant innovant procédural

non procédural

Les taux de procéduralité et d'innovation • Dépendent de l'expérience, de la connaissance du domaine, • Peuvent être différents pour le Commanditaire et le Maître d'œuvre.

Dépendance Dépendance, et donc vulnérabilité, vis à vis de :

• l’environnement d’exécution, • d’autres applications. exple :

• comptabilité analytique • commande processus industriel • jeu vidéo


b) Facteurs sur l’utilisation

Criticité critique de sûreté : des vies humaines sont en jeu

appareil domestique, transport, processus industriel, info. médicale critique de mission : les enjeux sont importants

financier : réseau bancaire, CB économique : perte de marché , désorganisation de l'activité sociaux : administration (sécu, retraites, élection), ressources humaines

non critique : les conséquences d’une défaillance sont minimes et/ou récupérables. Dans toute entreprise, il y a 1 ou 2 logiciels portant sur son activité principale : ils sont critiques de mission. La criticité peut être pour le maître d'œuvre

Durée de vie brève : Logiciel utilisé UNE seule fois : migration d’un environnement à un autre, basculement de la numérotation téléphonique, passage à l’Euro. Logiciel à utilisation limitée dans le temps : programme de test, gestion d’une manifestation. très longue : RITA : conçu en 72, opérationnel en 80, vendu à l’armée US en 88 UNIX : conçu en 70, diffusé à partir de 85 Caravelle : de 1955 à 1995. Les programmes restent en exploitation bcp plus longtemps que prévu. Avant les préparations pour le passage à l’an 2000, beaucoup de programmes avaient plus de 20 ans.

Cible Nombre et hétérogénéité :

• des utilisateurs, • des sites de déploiement, • des configurations, des versions du logiciel, • des plates-formes d'exécution


Utilisateurs logiciel embarqué, enfoui : logiciel intégré dans un système, non accessible logiciel grand public : l’utilisateur n’a aucune obligation à utiliser le logiciel, grande diversité d’utilisateurs. logiciel professionnel : utilisateurs formés et captifs fréquence d’utilisation : nbre d’utilisations / période (souvent ?) tx d’utilisation : durée d’utilisation / période (longtemps ?)

c) Facteurs sur le processus

Partenariat

Commanditaire maître d’ouvrage

Développeur maître d’œuvre

Utilisateur

besoincommande

produit

développement interne logiciel sur mesure ou adaptation d’un progiciel sous-traitance

totale ou partielle (définition, réalisation, mise en exploitation) pour le marché logiciel générique, progiciel ; commande publique, ou logiciel pour les clients On peut avoir des configurations différentes pour la spécification, le développement et le déploiement. La position relative des partenaires détermine la nature de leurs relations contractuelles, leur mode de coopération.


Compétence et disponibilité des partenaires Caractéristiques des participants au projet.

Développeur expérience dans le domaine compétence technique

Commanditaire & Utilisateur compréhension des besoins, définition de la commande gestion du partenariat

Technologie Comment travaille le maître d’œuvre et les autres partenaires ?

méthodes de conception, de programmation, de test, de gestion de projet, ... outils utilisés techniques informatiques utilisées : IA, BD, réseau, approche objet, ...

Déploiement Comment le logiciel est-il installé ?

unitaire : l’ensemble du logiciel est installé en une seule fois. progressif

• extension de la cible (utilisateurs pilotes) • extension des fonctions (installation incrémentale)

Contraintes de budget et de délai en niveau en rigidité pénalités de retard extensibilité de l’enveloppe financière


Conclusion Indépendance des facteurs même s'il existe certaines corrélations statistiques entre eux exple : critique de sûreté – informatique industrielle durée de vie brève – déploiement unitaire diversité de la cible – système d'information exercice : établir la matrice de corrélation entre les facteurs. Les facteurs sont très nombreux et dans l’ensemble indépendants => la variété des projets est considérable => l’expérience est difficile à capitaliser. Le profil d'un projet La valeur associée à chacun des facteurs permet de caractériser un projet, d’évaluer son profil selon 2 paramètres essentiels : • la difficulté, complexité : détermine la probabilité d’échec • le risque : marge d’incertitude sur l’évaluation de la difficulté,

due à l'insuffisance des connaissances sur le projet. Chaque facteur contribue à la difficulté et/ou au risque, avec une intensité dépendant de sa valeur. Il existe des grilles d'évaluation, par exemple Eurométhode. Viabilité d’un projet Les valeurs associées aux facteurs peuvent être interprétées comme des contraintes sur :

• le produit et son utilisation • le processus de développement

Ces contraintes ne s’additionnent pas simplement, elles interagissent exple :

innovation + & rigidité + => risque d’échec critique + & compétence - => échec taille + & technologie - => échec

Il faut équilibrer les contraintes imposées par l'ensemble des facteurs, la difficulté et le risque du produit doivent se compenser avec celles du processus. En fonction des objectifs du projet (les contraintes imposées par les facteurs principaux), il faut relâcher les contraintes occasionnées par les facteurs secondaires de façon à avoir une difficulté et un risques "raisonnables". C’est le propre d’un « bon » Chef de Projet de savoir évaluer la viabilité d’un projet exple :

forte contrainte budgétaire => réduire la taille, le taux d’innovation très innovant => déploiement progressif acquérir des compétences dans un domaine => embaucher du personnel compétent => allonger budget et délais


3. Les critères de qualité du logiciel La « crise du logiciel » Conférence de l’OTAN, à Garmish (Allemagne), 1968 :

L’informatique ne répond pas aux attentes qu’elle suscite, coûte très cher et désorganise les entreprises => introduction de l’expression « Génie Logiciel » (Software Engineering).

Etude sur 8 380 projets (Standish Group, 1995) :

• succès : 16 % • problématique : 53 % défaut de budget, de délai ou de fonctionnalités • échec : 31 % abandonné

Le taux de succès décroît avec la taille des projets et la taille des entreprises. Quels sont les symptômes de la crise, les motifs d’insatisfaction ? Inversement, qu’attend-on d’un « bon » logiciel, quelles sont ses qualités ? Pour chaque facteur de qualité,

• Sa définition, en quoi consiste-t-il ? • Conséquences de la non-qualité, son impact ? • Comment le mesurer ? • Comment l'obtenir ?

La recherche de solutions à ces problèmes a déterminé les évolutions de l’informatique, pour une part.


Utilité Les logiciels ne répondent pas aux besoins, ce sont des outils qui n’offrent pas les services, les fonctions utiles. Mauvaise relation entre : • le besoin effectif, tâche que doit accomplir l’utilisateur • l’outils, fonctions offertes pas le logiciel

Développeur Utilisateur

besoin exprimé

commande

logiciel produit

Commanditaire

Distorsion introduite par chaque partenaire, à l’émission et à la réception :

Le besoin exprimé correspond-il au besoin réel ? Le besoin exprimé est-il bien compris ? La commande est-elle conforme au besoin ? . . . .

Solutions : • emphase sur l’analyse des besoins, • améliorer la communication (=> langage commun, démarche participative), • travailler avec rigueur. Bilan : de grands progrès.

Utilisabilité Les logiciels sont difficiles d’emploi, donc

• sous-employés, • mal employés => faible productivité, résultats non conformes.

Facilité d’apprentissage cf. fréquence d’utilisation comprendre ce qu’on peut faire avec le logiciel, et savoir comment le faire.

Lié à la constitution d'une représentation mentale du logiciel et à la mémorisation. Facilité d’utilisation, maniabilité, efficience cf. taux d’utilisation importance de l’effort nécessaire pour utiliser le logiciel à des fin données, tx d'erreurs. Solutions : • analyse du mode opératoire des utilisateurs, • Adapter l’ergonomie des logiciels (physiologique et cognitive) aux utilisateurs. Bilan : Ce problème s’est intensifié avec la banalisation de l’informatique : • concerne plus d’utilisateurs, qui passent davantage de temps devant des écrans • les utilisateurs sont moins motivés. De nombreux progrès restent à faire.


Fiabilité Les logiciels tombent en panne, les pertes induites sont considérables : coût de détection des erreurs + coût de localisation, d’identification + coût de correction + manque à gagner d’utilisation correction, justesse, conformité : le logiciel est conforme à ses spécifications, les résultats sont ceux attendus. Validité : Conformité aux besoins effectifs, englobe toutes les qualités requises par le client. robustesse, sûreté : le logiciel fonctionne raisonnablement en toutes circonstances, rien de catastrophique ne peut survenir même en dehors des conditions d'utilisation prévues fiabilité : mesures quantitative du taux de panne, probabilité de fonctionnement sans panne

MTBF : Mean Time Between Failure MTTF : Mean Time To Failure

Disponibilité : pourcentage du temps calendaire pendant lequel le système est utilisable. Taux d'erreur : nombre d'erreurs par KISL Solution : • utiliser des méthode formels, • langage et méthode de programmation de haut niveau, • vérifier, tester • Progiciels. Bilan : La situation s’est améliorée, des vies humaines sont mises sous la dépendance de logiciels. Mais du logiciel est (presque) toujours à l’origine des grands échecs (ARIANE V, ...), c’est l'un des freins à l’emploi de l’informatique.

Interopérabilité, couplabilité Un logiciel doit pouvoir interagir en synergie avec d’autres logiciels.

Solutions : • Bases de données (découplage données/traitements), • "Externaliser" certaines fonctions en utilisant des "middlewares"

ayant une Application Program Interface bien définie • Standardisation des formats de fichiers (non propriétaires), des protocoles de communication • Les ERP Bilan : • Nets progrès pour l’intégration locale de qq applications. • Pas de solution pour la cohérence globale. nv problème : la gestion du parc applicatif Comment assurer la cohérence, l’interopérabilité, la complémentarité de centaines d’applications et BD ? Que faire des SI d’entreprises qui fusionnent ? Le pb est de concevoir l'urbanisme d'un SI (et non simplement l'architecture d'une application) Dictionnaires des Données de l’entreprise : échec.


Performances Les logiciels ne satisfont pas les contraintes de temps d’exécution.

solutions : • machines + performantes • logiciels + simples Bilan : performance du matériel : +++ simplicité des logiciels : --- (syndrome du spectaculaire, de « l’usine à gaz ») Collusion Intel / Microsoft ??

Portabilité Un même logiciel doit pouvoir fonctionner sur différentes machines.

Solutions : • rendre le logiciel indépendant de son environnement d’exécution (cf. interopérabilité) • machines virtuelles. Bilan : Résolu, par le marché.

Réutilisabilité Dans la plupart des logiciels,

80% du code est du « tout venant », que l’on retrouve ± dans tout logiciel, 20% est spécifique. => espoir de gains considérables.

Solutions : • abstraction, généricité, exple : MCD générique de réservation • construire un logiciel à partir de composants prêts à l'emploi, « on the shelf », approche objet • les "Patterns" Bilan : • L’importance de ce pb s’accroît avec le développement de l’informatique. • Réutiliser non seulement le code, mais aussi les modèles conceptuels. • On ne sait pas faire, malgré de nombreuses recherches :

- pb d'interopérabilité, caractériser tous les éléments de l'interface - aucune bibliothèque n'a le temps de devenir mature, du fait de l'évolution TL

De manière générale, un patron constitue une base de savoir-faire pour résoudre un problème récurrent dans un domaine particulier. L’expression de ce savoir-faire : 1. permet d’identifier le problème à résoudre par capitalisation et organisation d’expériences, 2. propose une solution correcte et si possible consensuelle pour y répondre, 3. offre les moyens d’adapter cette solution au contexte spécifique. Ils facilitent le processus d’ingénierie des systèmes en proposant des artefacts prédéfinis, adaptables à des problèmes similaires et à des technologies différentes d'implantation. Les premiers patrons dans le domaine de l'ingénierie du logiciel ont été présentés par K. Beck et W. Cunningham lors de la conférence OOPSLA de 1987.


Maintenance Un logiciel ne s’use pas !

Et pourtant la maintenance absorbe les 2/3 des coûts du logiciel, le double du développement. Maintenance corrective Identifier et corriger les erreurs : défauts d'utilité, d'utilisabilité, de fiabilité, ... • Identifier : quelle partie du code est à l'origine du pb ? ( propagation des erreurs) • Quel est l'impact d'une modification ? (la plupart des corrections introduisent de nvelles

erreurs) • Les coût des corrections augmentent exponentiellement avec le délai de détection –> nvelle livraison (release) Maintenance adaptative Ajuster le logiciel pour qu’il reste en service, continue à remplir son rôle, compte tenu de l’évolution : • des environnements d’exécution, • des fonctions à satisfaire, • des conditions d’utilisation. exple : changement de SGBD, de machine, des taux de TVA, an 2000, €Euro, ... Maintenance perfective, d’extension Accroître/améliorer les possibilités du logiciel exple : les services offerts, l’interface utilisateur, les performances, ... –> nvelle version Nature des actions de maintenance (Etude 1980) :

• modification des exigences : 42% • modification de la structure de données : 17,5% • corrections d’erreurs d’algorithme : 10% • modification du matériel : 6,5% • performance, interface, documentation, ... 24%

Objectifs • réduire la quantité de maintenance corrective (logiciel 0 défaut) • rendre moins coûteuses les autres maintenances. Solutions • améliorer les symptômes précédents • anticiper les changements à venir, • vérifier, tester, • modularité (limiter l’impact d’une modification), • paramètrer (modifier les données plutôt que le code) : structure de données complexes et

algo simples • Progiciels Bilan Des progrès, mais les besoins augmentent !


La maintenance est difficile du fait de : - l'évolution technologique - la complexité du logiciel => introduction de nouvelles erreurs ! Toute opération de maintenance dégradent la qualité d'un logiciel

Les coûts Le niveau Le développement du logiciel coûte très cher = 200F / ligne. Le logiciel est une industrie de main d’œuvre => le coût est proportionnel à l’effort (temps passé) : 15 lignes / jour / personne. Le coût varie de 1 à 5, en fonction du logiciel. La maîtrise L’évaluation a priori des coûts est très difficile,

comme tjs quand il s’agit de créer un produit unique, nouveau, complexe (cf Travaux Publics, cinéma, ...) Solution : • utiliser des langage de haut niveau, plus concis • automatiser, améliorer la productivité • standardiser, réutiliser des composants Bilan : • Des progrès dans les niveaux de coût,

mais les logiciels sont de + en + complexes et le coût croît exponentiellement avec la taille. • Des progrès dans les modèles théoriques de prévisions de coût du développement

Les délais Le niveau Les délais de livraison sont longsdurée intrinsèque (20 KISL --> 12 à 18 mois), due à

l'incompressibilité des activités • manque de disponibilité des personnels nécessaires, => Entre la formulation initiale du besoin et la fourniture du logiciel, les besoins ont changés ! La maîtrise Retards de livraison des logiciels, pb de ponctualité • mauvaise évaluation a priori (intrinsèque + aléas) • difficulté de planifier des ressources nécessaires (lisser la charge),

compte tenu de l'instabilité de la demande

Solution : • cf solutions pour les coûts • mieux organiser le travail, utiliser des progiciels Bilan : Cf. les coûts. Remarque : L'allongement des délais provoque l'augmentation des coûts, la mauvaise maîtrise des coûts résulte (en partie) de la mauvaise maîtrise des délais


La qualité du logiciel On vient d’énumérer les facteurs de qualité du logiciel.

La qualité est l’ensembles des caractéristiques d’une entité qui lui confèrent l’aptitude à satisfaire des besoins, exprimés ou implicites.

Une entité = • un produit, • un processus, procédé, • un service, organisme, ...

L’optimisation de chaque facteur est exponentiellement coûteuse. Ces facteurs sont conflictuels => il faut choisir / déterminer les plus importants, en fonction du projet. Pour pouvoir contrôler la qualité d’un logiciel, en cours de réalisation ou à la livraison, il faut :

• leur affecter une valeur précise, • et donc disposer d’une métrique pour chacun des facteurs pour savoir les mesurer Le Génie Logiciel Elaborer des outils et des méthodes de travail permettant d’obtenir ces qualités a priori L’Assurance Qualité Garantir que tout processus de développement utilise correctement ces outils et méthodes, de façon à produire un logiciel de qualité.


4. CONCLUSION

Bilan Le logiciel est un produit encore mal compris car très abstrait, très spécifique, manque d’expérience Science (science du calcul, du traitement de l’information) ou Technique (utilisation des ordinateurs) ? => Que peut-on faire avec du logiciel ? => Les progrès technologiques sont très importants mais diffusent mal La production du logiciel est mal maîtrisée • La qualité des produits n’est pas satisfaisante

=> importance du processus de production • Comment passer d’une obligation de moyens à une obligation de résultats ? • Le marché s’organise (très) lentement

grande variation dans les prix clientèle captive (IBM, MicroSoft) confusion conseil / prestataire de service

Niveau des savoir-faire –> qualité des processus –> qualité des produits

Capability Maturity Model (CMM) 1. initial : totalement informel, résultat aléatoire 2. répétitif : savoir reproduire un projet qui a réussi (a une mémoire) 3. défini : planifier et organiser (utilise des modèles, méthodes) 4. contrôlé : suivre le plan (suit et contrôle de ce qui est fait) 5. optimisé : prendre les meilleurs décisions

ou SPICE : Software Process Improvement & Capability dEtermination, level 2 (requirements management, project management, subcontract management, quality assurance, configuration management); level 3 (organisational process focus and definition, training, integrated software management, product engineering, intergroup coordination, peer reviews); level 4 (quantitative process management, software quality management); level 5 (defect prevention, technology change management, process change management).


Solutions Travailler avec méthode

Logiciel

Technologie

Organisation

Compétences

La technologie Il y a eu beaucoup de progrès depuis 25 ans, on sait faire des logiciel de qualité si l’on s’en donne les moyens. La compétence des professionnels L’évolution des technologies est très rapide, leur maîtrise est difficile Leur rôle est souvent mal (re)connu Grande importance du "facteur humain" dans tt projet L’organisation Le développement de logiciels est une activité collective qui doit être gérée. exple:

• mvse planification (an 2 000) • objectifs mal définis • mauvaise communication entre le client et le fournisseur • motivation des participants • mauvaise allocation de ressources

La bonne Gestion d’un Projet est essentielle à sa réussite.


Les méthodes 1) des langages, formalismes, « modèles »

utilisés pour formuler les résultats exple : UML, E/A de Merise

2) une démarche, procédure • les tâches à réaliser, avec les résultats auxquels elles doivent aboutir • un ordonnancement de ces tâches, défini de façon - procédural, - ou déclaratif. 3) des procédés, techniques guide pour accomplir une certaine tâches exple : normaliser une BD fusionner plusieurs BD étudier l’activité d’un utilisateur tester une procédure évaluer des coûts 4) des outils


Documents

Le caractéristiques du logiciel