Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Découpage temporel d'un projet
Par rapport au temps complet (100%) dans la gestion d'un projet, quelle proportion de temps prendriez-vous pour réaliser les tâches suivantes ?
Etude de faisabilité et proposition informatique.
Architecture et calcul du risque.
Conception générale.
Codage et test unitaires.
Tests d'intégration.
Test de qualification.
A+
La proportion va dépendre du niveau de qualité requis pour le projet. Plus le niveau de qualité demandé est élevé, plus les temps de conception et de test serons élevés en proportion du temps de codage et de proposition.
Ensuite une chose m'étonne lorsque je lis vos tâches :
Le calcul du risque ne doit-il pas être fait lors de l'étude de faisabilité/proposition informatique (pour chiffrer correctement commercialemant parlant) ?Etude de faisabilité et proposition informatique.
Architecture et calcul du risque.
Conception générale.
Codage et test unitaires.
Tests d'intégration.
Test de qualification.
Ensuite, si on se débrouille bien, on peut utiliser certains tests d'intégration comme tests de qualification pour éviter de répéter des tests identiques sur des étapes différentes.
Puis-je savoir pour quelles types d'applications/domaine vous gerez des projets ?
Tes réflexions sont intéressantes.
D'ailleurs bien souvent j'inclus le calcul du risque et l'architecture dans l'étude de faisabilité.
Ensuite comme tu le fais remarquer, certains tests d'intégration et de qualification peuvent souvent être commun mais la nuance que je fais (mais je peux me tromper dans la terminologie des termes utilisés) est que les tests d'intégration sont réalisés dans la société et en local (via parfois des simulations du système final) et les tests de qualification sont réalisés sur le système complet (bien souvent chez le client) en fonctionnement.
A+
Oui, il est préférable comme tu le fais déjà d'inclure le calcul du risque et une partie de l'architecture dans l'étude de faisabilité (à mon sens tu ne peux pas inclure toute l'architecture, sinon cela veut dire que tu démarres déjà le projet...ce sont juste les espects les principes de l'architecture que l'on aborde...)Tes réflexions sont intéressantes.
D'ailleurs bien souvent j'inclus le calcul du risque et l'architecture dans l'étude de faisabilité.
Ensuite comme tu le fais remarquer, certains tests d'intégration et de qualification peuvent souvent être commun mais la nuance que je fais (mais je peux me tromper dans la terminologie des termes utilisés) est que les tests d'intégration sont réalisés dans la société et en local (via parfois des simulations du système final) et les tests de qualification sont réalisés sur le système complet (bien souvent chez le client) en fonctionnement.
A+
Pour ce qui est de l'intégration et de la qualification, je ne suis pas tout à fait d'accord.
Pour moi l'intégration consiste à vérifier que le logiciel fonctionne bien sur la cible sur laquelle il sera. On s'assure dans ce cas aussi de son comportement dans les cas limites ("le pire des cas") et l'on vérifie les performances de celui-ci.
Ensuite pour ce qui est des test de qualification, on vérifie que le système complet est conforme à des critères d'acceptation fournis par un client et/ou une norme. Ces critères d'acceptations sont définies dans un environnement précis qui peut tout autant être simulé dans l'entreprise en local (si elle réuni les critères environnementaux demandés) que chez le client.
Cela concerne uniquement la qualification d'un équipement.
Maintenant, il y a aussi un autre type de qualification, la qualification d'un système complet dont l'équipement peut être membre. Dans ces conditions, c'est au systèmier d'effectuer ce test de qualification.
Dans le cas ou le systèmier serait aussi équipementier, il y aura donc 2 étapes de qualification, la qualification équipement puis la qualification systèmes.
Ensuite par exemple dans l'automobile, l'aéronautique... il y aura enfin une qualification du véhicule dans sa globalité.
Du coup il faut bien distinguer de quel type qualification dont on parle pour déterminer d'environnement et les restrictions liées à ces qualifications.
Pour quel domaine avez vous à réaliser votre projet ?
Est-ce du logiciel embarqué ?
Il s'agit d'applications J2EE pour des systèmes d'acquisitions de données via le protocole de communication des électroniques de mesures.
A+
Ok,
Et quelle niveau de qualité est requis ?
A+
Envoyé par exterieur
Ok,
Et quelle niveau de qualité est requis ?
A+
Et bien dis-moi comment tu considères les choses et combien de temps cela te prendrait.
J'aimerais vraiment un retour d'expérience sur ce sujet.
Merci et a+
Et bien je ne peux pas te dire car déjà çà dépend du niveau de qualité requis et puis J2EE moi je ne connais pas donc je ne peux pas te renseigner dans ton contexte.Et bien dis-moi comment tu considères les choses et combien de temps cela te prendrait.
J'aimerais vraiment un retour d'expérience sur ce sujet.
Merci et a+
Je suis plutôt habitué au contexte du logiciel embarqué pour l'aéronautique....
Demande aux gens qui font du J2EE.
A+,
Bon ce n'est pas le plus important.
Je développe aussi des applications swing pour l'aéronautique : dis-moi, s'il te plait, ton découpage temporel.
Merci d'avance.
SI je reprend ton découpage du départ, je répartirais à peu près comme ceci :
Etude de faisabilité et proposition informatique/Pseudo Architecture et calcul du risque -> 5% (si on se base sur du retour d'expérience...).
Conception générale (et détaillée) -> 15 %
Codage et test unitaires (rédaction prodédure+ test) -> 15 %
Tests d'intégration (rédaction prodédure+ test) -> 40%
Test de qualification (rédaction prodédure+ test) -> 40%.
J'ajouterai 5% pour la rédaction des documents de l'assurance qualité tout au long du projet.
Voili voilou.
Et toi, quel serait ton découpage ?
A+.
Tu es à plus de 100% : tu ne peux pas faire ce découpage.
A+
OUUPSSS !!
Etude de faisabilité et proposition informatique/Pseudo Architecture et calcul du risque -> 5% (si on se base sur du retour d'expérience...).
Conception générale (et détaillée) -> 10 %
Codage et test unitaires (rédaction prodédure+ test) -> 15 %
Tests d'intégration (rédaction prodédure+ test) -> 35%
Test de qualification (rédaction prodédure+ test) -> 30%.
J'ajouterai 5% pour la rédaction des documents de l'assurance qualité tout au long du projet.
Voilà, là j'crois que les 100% y sont...
Qu'en penses-tu ?
Merci exterieur.
Il n'y a pas d'autres avis ?
A+
Bonjour,
Pour ma part, j'utilise les chiffres suivant pour qualibrer mes estimations :
Cadrage de la solution 5%
Développement (Conception) 30%
Développement (Fabrication) 20%
Test d'intégration 25%
Qualification 20%
La charge d'encadrement, doc et assurance qualité est intégrée elle représente entre 8% et 12% répartie uniformément sur le projet (selon le nombre d'intervenant sur le projet)
Il y a une cohérence avec les chiffres d'extérieur.
On a une charge de conception plus élevée et une charge de qualification plus faible.
Ces chiffres sont plutôt bien vérifiés dans mon contexte d'entreprise et de projet.
En faite, pour nos estimations, nous utilisons souvent la méthode des points de fonction.
Les coefficients ont été affinés au fur et a mesure avec les projets.
Ces coeff. sont vraiment le reflet d'une organisation et sont à mon avis difficilement transférable.
Voila
Merci, c'est à peu près ce que j'ai dans ma société mise à part les tests de qualification qui sont près de 15%.
A+
Oui, il est normal que les proportions des test de qualif et intégration puissent varier d'un projet à un autre même si le volume de dev est le même.
En effet, les proportions dépendent des niveau de test requis par les clients ou une norme...
Du coup, je pense qu'on est cohérents dans notre chiffrage qu'il faut bien évidemment adapter à chaque contexte ;-)
petite précision!!!
Les chiffres que je présente sont des moyennes sur un ensemble important de projet. Les écarts types peuvent être significatifs, mais c'est un bon point de départ pour le chiffrage.
La méthode des points de fonction permet d'affiner le chiffrage lorsque que l'on réalise un projet avec des briques connues par l'organisation - se sont les coefficients qui sont à mon avis peu transférable.
voilà pour la petite précision.
Sinon, effectivement on est plutôt d'accord dans l'ensemble. Pour voir des chiffres différents il faudrait peut-être avoir des chiffrages avec des cycles projets également différent, non!!?
Je trouve votre temps pour le dev et test unitaire un peu court...
Je mettrais 20%
je réduirais la qualification sur site.
Par rapport au temps complet (100%) dans la gestion d'un projet, quelle proportion de temps prendriez-vous pour réaliser les tâches suivantes ?
Etude de faisabilité et proposition informatique. 5%
Architecture et calcul du risque. 5%
Conception générale. 20%
Codage et test unitaires. 40%
Tests d'intégration. 15%
Test de qualification. 15%
A+
j'ai mis les pourcentages à la suite de chaque ligne, c'est à la louche, on pourrait réestimer plus précisément encore à la fin de la conception.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager