Résulats de l' enquête sur les exigences ExiOuest2009

ExiOuest 2009

Résultats de l’enquête ExiOuest 2009
sur l'ingénierie des exigences

Enquête en ligne de Juillet à Octobre 2009 sur www.exibri.com

1 Résultat de l’enquête ExiOuest 2009 au 20 Octobre (53 réponses). www.exibri.com

ExiOuest 2009

ExiOuest 2009 a reçu plus de 80 réponses.
Nous avons éliminé la trentaine de réponses vides.

Les données ci-dessous correspondent donc au 51 réponses pertinentes
reçues à la date du 20 Octobre 2009.

Enquête animée par Norbert Khalil et Daniel Lucas-Hirtz, www.exibri.com,
outillée avec limesurvey, www.limesurvey.org


Le public de l’enquête

• Le public de l'enquête
• Les cycles de développement (cycle en V, agilité, ..)
• Les référentiels CMMI, ISO9001 et ITIL
• Les forfaits
• L’ingénierie des exigences
• La traçabilité
• Le "feature creep"
• Réutilisation, héritage et lignes produit
• Conclusion


Les entreprises

Et plusieurs autres qui n’ont pas voulues être citées

Une majorité de grands groupes

« Nombre de collaborateurs de votre groupe/entreprise ? »

1-9 p

10-49 p
41%
50-249 p

250-999 p

1000-4999 p
59%
5000-...

0% 5% 10% 15% 20% 25% 30% 35% 40% 45%

59% des sondés font partie de groupes de plus de 1000 personnes.


Un public centré sur Rennes

« Localisation de l'entité dont vous êtes représentatif ? » (choix multiple)

Paris 11%
38%
Rennes / bassin Rennais 38%

60% Bretagne hors Rennes 11%

Grand ouest hors Bretagne 11%

Reste de la France 8%

Europe hors France 11%

Amérique 5%

Asie 3%

Reste du monde 0%

38% des sondés sont localisés à Rennes et dans le bassin Rennais,
60% dans le grand Ouest


Des entreprises souvent internationales

« Localisation de votre groupe / entreprise ? » (choix multiple)

Paris 15%

Rennes / bassin Rennais 16%

Bretagne hors Rennes 9%

Grand ouest hors Bretagne 9%

Reste de la France 11%

Europe hors France 14%

Amérique 10%
42%
Asie 11%

Reste du monde 7%

42% des sondés dans des groupes présents à l’international


Télécom et multimedia

« Domaines d'activité de votre entreprise ?» (choix multiple)

Télécommunications 40
59%
Multimédia 19

Administration, finance, gestion 10

Automobile 8

Militaire, défense 8

Transports 6

Entertainment (jeux video etc.) 5

Grande distribution 5

Aérospacial 4

Médical / soins 3

Autre 4

59% des entreprises dans les télécommunications et le multimédia


« produit » et « embarqué »

Types d’entreprise ? Types de produits ?

59 % de donneurs d’ordres et 41% dans l’ embarqué
27% dans les SI et
35% de SSII
32% polyvalents


Les cycles de développement (cycle en V, agilité,..)

• Les forfaits
• Conclusion


Durée moyenne d’un nouveau produit = 10 mois

Durée de développement d'un nouveau produit ?

7% Entre 0 et 3 mois

Entre 3 et 7 mois

Entre 7 mois et un an

Entre 1 et 1.5 an

34%
> 1.5 ans

0% 5% 10% 15% 20% 25% 30% 35%

Seuls 7% des nouveaux projets durent moins de 3 mois
1/3 des sondés travaillent sur des produits avec des cycles > 1an


Des petites équipes

Nombre de ressources logicielles (personnes) pour un nouveau produit:

1-3p
47%
4-9p

10-29p

30-69p

70-119p

16% 120-200p

>200p

0% 5% 10% 15% 20% 25% 30% 35% 40%

47% des équipes font moins de 10 personnes
Seules 16% des équipes font plus de 70 personnes


Encore une majorité de cycles en V longs

Processus de développement logiciel utilisé:

60%

60% utilisent des cycles en V long
Seuls 15% des entreprises utilisent des cycles itératif court < 1 mois


1/3 des entreprises utilisent des méthodes agiles

Utilisez vous les méthodes agiles ?

39% ne connaissent pas les méthodes Agiles
Il y a un potentiel d’évolution: 22% des sondés les regardent de très près


L’ agilité encore expérimentale

Quelle proportion de vos projets suivent les méthodes agiles ?

73% 27%

73% des entreprises agiles l’utilisent sur une minorité de projets
27% des entreprises agiles l’utilisent sur une majorité de projets


Scrum loin devant les autres méthodes

Quelle méthode agile ? (choix multiples possible)

Scrum 47%

Philosophie interne 24%

XP 18%

Autre 5%

RUP 5%

*question posée à ceux qui utilisent les methodes Agiles ou regardent Agile de très près

¼ des sondés utilisent une méthode agile « maison »
Ceux qui utilisent XP (Extreme Programming) utilisent aussi Scrum


L’agilité: cibler l’essentiel des besoins

Quels sont selon vous les avantages des méthodes agiles ? (classement)

Se concenter sur l'essentiel des besoins du client 29%

Développement plus rapide 18%

Motivation des équipes 14%

L'avancement du projet est visible rapidement 13%

Modifications pendant le projet facilitées 10%

Présence du client 10%

Développements basé sur les tests 4%

Moins de documentation 1%

Tests automatisés 0%

L’ accélération du développement et la motivation des équipes sont
deux autres avantages fréquemment cités.


L’agilité: pas d’engagement sur les exigences

Quels sont selon vous les inconvénients des méthodes agiles ? (classement)

Pas d'engagement sur les exigences complètes 26%

Pas adapté aux projets complexes 21%

Pas d'engagement sur la durée totale 18%

Peu de conception et de documentation 13%
Peut causer des problèmes de réutilisation et de
10%
maintenance
Equipes peu cadrées 7%

Pas adapté à notre domaine 4%

Temps itératif trop court 1%

Qualité du logiciel moindre 0%

L’ adaptation aux projets complexe, l’engagement sur la durée et le
manque de conception/ documentation sont fréquemment cités.


Les référentiels CMMI, ISO9001 et ITIL

• Les forfaits
• Conclusion


ISO 9001 la plus utilisée puis CMMI et ITIL

Utilisez vous les modèles de référence ci-dessous: (choix multiples possible)

51%

CMMI

62%
ISO Oui
9001 Non
Incertain

22%

ITIL

0% 10% 20% 30% 40% 50% 60% 70% 80%


CMMI jugée la plus utile

Jugez vous ces modèles utiles à votre ingénierie logicielle ? (choix multiples possible)

0%
16%
CMMI 41%
41%
82%
3%

3% 37% Pas du tout
34%
ISO 9001 38% Pas vraiment
25%
0% Assez
Très
3%
9%
Non applicable
ITIL 22%
6%
59%

0% 10% 20% 30% 40% 50% 60%

82% jugent CMMI utile ou très utile pour le logiciel
37% jugent ISO 9001 pas vraiment utile


De nombreuses raisons de choisir CMMI

Quelles sont les raisons d'utiliser CMMI ? (classement)

Mettre en place le processus 19%

Demande au sein du groupe 18%

Ameliorer le processus 17%

Demande des clients 15% 41%

Standardiser le vocabulaire 15%

Donner une bonne image 8%

Maintenir l'équipe au top 7%

Dans 41% des cas le choix vient plutôt du haut: direction, client, image


Les forfaits - côté clients

• Les forfaits - côté clients
• Conclusion


Les clients plutôt satisfaits des forfaits

Etes vous satisfait lors de vos forfaits ? (réponses multiples)

De la rentabilité par rapport à un
dév en interne

Du nombre de ressources allouées

De l'expertise des ressources
allouées

Du surcoût lors des modifications Très satisfait
Assez
De la date de livraison Peu
De votre gestion des Pas du tout satisfait
modifications

De votre définition des exigences

De la coopération avec le(s) sous-
traitant(s)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

Hormis le coût, les clients sont satisfaits des forfaits de leurs sous-
traitant. La coopération est plébiscitée.


Les forfaits surtout motivés par le manque de ressources

Quels sont les raisons principales de faire du forfait ? (classement)

Palier le manque de ressource en interne 25%

Sous-traiter les travaux sans valeur ajoutée 23%

Libérer des locaux pris par l'assistance technique 16%

Palier le manque d'expertise interne 13%

Baisser les coûts de développement 11%

Gagner du temps 8%

Ne pas garder les personnes en assitance technique 4%

Le manque d’expertise interne ne représente que 13% des réponses


L’ éloignement est le principal inconvénient des forfaits

Quels sont les inconvénients principaux de faire du forfait ?

Inefficacité due à la distance et au controle nécessaire du
42%
sous-traitant

Dependence forte vis-à-vis du sous-traitant (problème pour
33%
les changements et la maintenance )

Ressources allouées pas assez compétentes 11%

20%
Ont souvent du retard 9%

Prennent le travail des équipes internes 5%

Coutent cher 0%

Seules 20% des réponses mettent en cause la compétence du sous-
traitant


Les forfaits - côté SSII

• Les forfaits - côté clients
• Les forfaits - côté SSII
• Conclusion


Les forfaits minoritaires qui se généralisent

Quel pourcentage de votre effectif travail au forfait

Plus des deux tiers des SSII font du forfait, mais moins d'un quart le
font de façon majoritaire.


Les SSII plutôt mécontentes de leurs forfaits

Etes-vous satisfaits lors de vos forfaits de (réponses multiples possibles)

Non applicable

De la rentabilité des forfaits pour Très satisfait
votre entreprise Assez
Peu

Des changements par le client en Pas du tout satisfait
cours du projet

De la définition des exigences de
la part du client

De l'implication du client

0% 10% 20% 30% 40% 50% 60% 70% 80%

Vu par les SSII, la définition des besoins et ses changements par le
client sont les problèmes majeurs des forfaits.


Rentabilité et efficacité motivent le forfait

Quelles sont les raisons principales de faire du forfait ? (classement)

Le forfait est plus rentable que l'assistance technique 32%

54%
Le forfait est plus efficace pour nos clients 22%

Le forfait est plus motivant pour les salariés 17%

Le forfait fidélise nos clients 15% 45%

Le forfait permet de gérér l'intercontrat 13%

Les SSII motivent le forfait par sa rentabilité et par son efficacité (54 %).
Dans 45% des cas ce sont des raisons annexes


L’ingénierie des exigences

• Les forfaits
• Conclusion


Une gestion des exigences peu satisfaisante ?
Etes vous globalement satisfait de la gestion des exigences logicielles ? (table de
questions)

Très
satisfait
par vos
sous- 33% 33% Assez
traitants 0%

par Peu
votre
0%
42% 42%
entité
Pas du tout
satisfait
par vos 37%
clients 14% 51% Question
non
applicable
0% 10% 20% 30% 40% 50%

51% des sondés sont peu ou pas du tout satisfaits de la gestion des exigences
par leur clients,
33% de celle de leur sous traitants,
et 42% de la leur propre.

Clients et marketing présents
Quel est le rôle des acteurs en phase de définition du produit ? (table de questions)

Collabore et
fournisseurs de logiciel 18%
(équipes externes) approuve
Collabore
équipe d'ingénierie 8%
(y compris validation) Absent mais
nécessaire
équipe marketing 8% Inutile
ou équipe produit

Question non
représentants 20% applicable
des utilisateurs

clients 10%

0% 10% 20% 30% 40% 50% 60% 70%

L’ingénierie, le marketing et les clients collaborent.
Les représentants des utilisateurs et les fournisseurs de logiciels sont en
revanches jugés « absent mais nécessaires » dans presque 20% des cas.


Des utilisateurs insuffisamment impliqués
Etes vous satisfait de l'implication des acteurs à la définition du produit ? (table de
questions)

fournisseurs de Très satisfait
logiciel 21%
0%
(équipes externes)
Assez
équipe d'ingénierie
16%
(y compris validation) 0%
Peu
équipe marketing
32%
ou équipe produit 3%
Pas du tout
satisfait
représentants
des utilisateurs 5%
34% 39%
Question non
applicable
clients
5%
34% 39%

0% 10% 20% 30% 40% 50% 60%

Dans 39% des cas, l’implication des clients et des représentants des
utilisateurs est jugée peu ou pas du tout satisfaisante


Des réunions clients toutes les semaines
Quelle est la fréquence de vos réunions avec les acteurs ? (table de questions)

Tous les jours
0%
représentants 34%
17% Toutes les
des
utilisateurs semaines
Tous les mois
46% 3%
43% En début et en fin
26%
clients de projet
Jamais

0% 10% 20% 30% 40% 50% Question non
applicable

Dans presque la moitié des cas, l’équipe rencontre le client au
moins toute les semaines.


Le produit montré à partir de l’intégration
Quand le client voit-il le produit (maquettes, prototypes, versions intermédiaires ..) ?

Le produit est montré au client tous les mois (ou plus souvent) dans
moins de 20% des cas.


Des spécifications rédigées par l’ingénierie
Qui rédige les documents de spécification et défini vos produits logiciels ?

Dans 52% les produits sont définis au sein des équipe d’ingénierie.


Outils de spec : 100% utilisent word et excel
Avec quel outil publiez vous vos spécifications ? (table de questions)

Pas d'outil 5% Toujours
(discussions) 50%
Sur papier / 0%
61% Parfois
post-it
Courriels et comptes 13%
rendus de réunion 5% Jamais
Outil bureautique texte 82%
type word & excel 0% Sans
Outil de dessin 16% réponse
type Visio 26%
Outil de modelisation 5%
UML 45%
Outil spécifique 16%
(ex. DOORS) 53%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

Word et excel sont utilisés de façon systématique par 82 % des sondés.
Les outils dédiés comme DOORS sont utilisés par 29% des sondés, ils ne sont
utilisés systématiquement que dans 16% des cas.

Capture des exigences par des ateliers
Quelles pratiques utilisez vous pour capturer les exigences ? (table de questions)

Observation des utilisateurs 6%
Toujours
sur site
Ateliers avec l'ingénierie 45% Parfois
et le marketing
Jamais
42%
Ateliers avec le client

3%
Prototypes papier

6%
Prototypes executables

User Stories façon 3%
agile (XP..)
Revues de la documentation 24%
existante

0% 10% 20% 30% 40% 50% 60% 70%

Les ateliers avec l’ingénierie et le marketing (90%) et avec le client
(87%) plébiscités pour la capture des exigences.


Archivage sur disque réseau
Comment archivez vous et publiez vous vos documents de spécifications ? (réponses
multiples)

Publication sur un disque partagé. 53%

Publication sur un outil de gestion documentaire
50%
(DMS)

Publication sur un outil web collaboratif (ex. TWiki). 33%

Envoi par mail 28%

Publication sur un outil de gestion des exigences
18%
(ex. DOORS).

Outil dédié utilisé dans 18% des cas
Les outils web collaboratif (ex. TWiki) dans 33% des cas.


Le CCB décide les changements de spec
Après qu'un document de spécification ait été approuvé, quelles sont les conditions
qui permettent de le modifier ?

Sous la responsabilité de l'auteur 15%

Après accord de l'équipe -
28%
pas de processus défini

Après accord du change control board -
18%
pas d'outil de gestion des change requests
56%
Après accord du change control board -
38%
change requests gérés par un outil dédié

Un référentiel de spécification « baseline » gouverné par une
autorité définie (change control board) dans 56% des cas.


Des changements tracés dans ¾ des cas
Pouvez vous identifier quelle modification documentaire correspond à un "change
request" donné ?

76%

Dans trois quart des cas, on peut identifier quelle modification
documentaire correspond à un « change request » donné.


Des documents à jour jusqu’à la livraison
Jusqu'à quand les documents de spécification sont ils maintenus à jour ?

Jusqu'à leur
17%
approbation

Jusqu'à la fin des
29% 66%
développements

Jusqu'à la livraison
20%
du produit

Tant que le produit
26%
est en utilisation

Tant que la ligne de
produit est en 9%
utilisation

Dans deux tiers des cas, les spécifications cessent d’être maintenues
à jour après la livraison du produit.


Des ingénieurs spécification rarement formés
Les ingénieurs spécification (analystes fonctionnels) sont-ils formés à l'ingénierie des
exigences ? (typiquement 3 jours de formation)


La traçabilité

• Les forfaits
• Conclusion


Une traçabilité peu outillée

Avec quels outils effectuez-vous la traçabilité ? (choix multiples possible)


Traçabilité pour la couverture et l’analyse

Quelles sont les bénéfices de la traçabilité ? (classement)

S'assurer de la couverture des tests, exigences clients etc.... 34%

Analyser finement les impacts d'une exigence 21%
38%
Déterminer les impacts lors d'une demande de
17%
changement

Structurer et gérer les éléments produits (ex. traçabilité par
13%
numéro de feature)

C'est de la perte de temps 8%

Autre 8%

Hormis la couverture, l’analyse et la recherche d’impacts
représentent 38%
13% la trouve utile pour structure les éléments produits.

La traçabilité non satisfaisante

Etes vous satisfaits de votre gestion de la traçabilité ?

57%

57% sont peu ou pas du tout satisfaits de leur traçabilité et seul 5%
sont très satisfaits.


Le "feature creep"

• Les forfaits
• Conclusion


Impact modéré du feature creep
« Souffrez vous de "feature creep" ? » (choix unique)
Feature crep: « Glissement incontrôlé du projet pour cause de prolifération des
nouvelles demandes de fonctionnalité ».

34%

66%

66% des sondés indiquent un impact modéré du « feature creep »
(en terme de délai, surcoût, ou bien défaut de qualité)


Causes du feature creep d’abord externe au projet

« Causes majeures de "feature creep" ? » (classement)

Changement d'avis du client 25%

58% Changement du marché 18%

Volonté interne (direction produit) de réorienter le produit 15%

Le besoin initial du client n'avait pas été identifié 16%

Changements internes au projet 17%

26%
La demande initiale explicite du client n'avait pas été
9%
capturée

58% des sondés indiquent une cause externe au projet
Seulement 26% des causes sont explicitement internes


Peu de métriques sur la volatilité des exigences

« Est ce que vous maintenez des métriques sur la volatilité des exigences ? »
(classement)

84% des sondés indiquent ne pas maintenir de métriques sur la
volatilité des exigences


Réutilisation, héritage et lignes produit

• Les forfaits
• Conclusion


Majoritairement des lignes produit
Basez-vous vos nouveaux produits sur le code, les tests et les spécifications d'un
produit pré-existant ("ligne produit") ?

Dans 2/3 des cas, l’ingénierie réutilise le code, les tests et les
spécifications d'un produit pré-existant – c’est-à-dire gère une (ou des)
ligne(s) de produits.


Les tests, champions de la réutilisation
Etes vous satisfaits de l'efficacité de votre ligne de produit ? (table de questions)

22% Très satisfait
Réutilisation 61%
des spécifications Assez

48% Peu
Réutilisation 43%
du code
Pas du tout
61% satisfait
Réutilisation 17%
Non
des tests
applicable
13%
Facilité de la 65%
customisation

Efficacité de votre 9%
26%
outil de gestion de
la ligne de produit

0% 10% 20% 30% 40% 50% 60% 70%

Des tests réutilisés plus efficacement (61%) que le code (48%) , lui-même mieux
réutilisé que les spécifications (22%) .
Une customisation moyennement efficace, et des outils de gestion de ligne
produit inexistants ou pas suffisamment efficaces.


Conclusion

• Les forfaits
• Conclusion


Conclusion

Merci à tous ceux d’entre vous (plus de 50 personnes) qui ont pris le temps de
répondre à ce questionnaire !

Comme convenu nous envoyons dans les prochains jours un benchmark personnel
et confidentiel pour chaque réponse qui contient une adresse courriel.

Nous espérons que ces données permettrons à tous les acteurs de mieux
comprendre la place de l’ingénierie des exigences telle qu’elle est perçue par
les acteurs de l’informatique dans l’ouest.

Vous retrouverez nos analyse de ces résultats sur www.exibri.com, rubrique
blog.

Droits de reproduction :
Exibri autorise (et encourage) la reproduction de tout ou partie des informations de ce
document à condition qu’exibri soit cité comme source de l’information


Résulats de l' enquête sur les exigences ExiOuest2009

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Résulats de l' enquête sur les exigences ExiOuest2009

Ähnlich wie Résulats de l' enquête sur les exigences ExiOuest2009 (20)

Résulats de l' enquête sur les exigences ExiOuest2009