Discussion :

[selig]

Bonjour à tous,
je souhaite chiffrer la réalisation d'une application sous access avec au delà de la BDD, des formulaires, des états et des modules de calcul.

Disposez-vous d'un abaque de chiffrage : quel est le nb jour homme de réalisation pour chaque composant access ?

Merci de votre aide

[Tofalu]

Bonjour

Avec un cahier des charges aussi précis, cela va de 17 minutes (cf la video de maxence hubiche) à plusieurs mois (cf des projets jamais terminés)

Le chiffrage s'obtient sur une base de cahier des charges. C'est comme si vous appeliez votre concessionnaire : "J'ai une panne, ça va couter combien et prendre combien temps ?"

[selig]

Je ne souhaite pas que vous me disiez le cout de l'application mais le cout unitaire par composant et par complexité (rôle de l'abaque) généralement constaté sur un projet.
Combien de jour homme en moyenne faut-il pour construire un formulaire simple, moyen, complexe ? (idem pour un état ou pour un module)
Je dirai par exemple qu'un formulaire simple est un formulaire
- avec 1 à 6 champs issus d'une ou 2 tables
- 1 ou 2 boutons simples (Ok - Annuler)
- Contrôles simples
- Règle de gestion simples
Combien de jour homme faut-il pour le développer et le tester ?

Merci

[random]

une petite heure si on choisit un graphisme simple et si on connait le produit
disons une demie journée si on veut soigner la présentation
une journée (voire une semaine) si c'est le premier de la base
tout dépend où on place la barre

[Tofalu]

Un formulaire simple tel que vous le décrivez prend 5 minutes à créer, 5 minutes à tester (j'exagère à peine, tout est intégré via des assistants)

L'allongement des temps de développement survient dès qu'il faut coder, ce qui n'est pas le cas pour un formulaire simple.

Le code aura deux objectifs qui peuvent être séparés ou unifier :

- augmenter les performances (par exemple sur des statistiques quand les requêtes sont trop lentes)
- traiter des règles de gestion spécifique (genre, je veux créer un pdf à chaque création de commande et ce de manière automatique, qu'il soit envoyé automatiquement par e-mail au client, et que parralèlement, cela alimente un fichier excel qui sera ...)

Dès que le vba est utilisé, non seulement les temps de developpement augmentent mais aussi ceux de tests et ceux de maintenance. Pour peu que l'on utilise des composants moins standards tels que les onglets, listview et treeview et on se rend compte qu'il y a toujours un truc qui cloche.

Disons à la louche :

Formulaire simple : 1/4 jour homme
Formulaire moyen : 1/2 à 1 jour homme
Formulaire complexe : 1 à 3 jours homme

[selig]

Merci pour vos réponses.
Si vous avez les mêmes ratios sur les états et les modules, je suis preneur.

[Tofalu]

En ce qui concerne les états, c'est surtout la définition de la charte graphique générale et à vrai dire du premier état qui est parfois laborieuse. Le code est plus rare et se limite aux états que l'on pourrait qualifier de complexe.

Si on applique les états à nos formulaires du dessus, je dirais

formulaire simple -> état simple
formulaire moyen -> état simple
formulaire complexe -> état complexe voire très complexe

Pour les rapports statistiques c'est quitte ou double. Soit les mécanismes de base convienne auquel cas c'est très rapide, soit ... non ... et là ça peut être vite galère.
Si on compte la recherche d'une solution à un problème de mise en page peu commun dans le temps de développement, alors comme pour les formulaires, il faut parfois compter plusieurs jours. En revanche, si la solution est déjà connue du développeur, en quelques heures, il peut vous produire un résultat bleufant.

Quant aux modules ... tout dépend de l'orientation du projet et du cahier des charges. Là c'est impossible de définir, sachant qu'une bonne partie de l'IHM est souvent reportée dans les modules. POO, pas de POO, accès aux données DAO, ADO, API Windows, automation, etc...

De 0,1 à des dizaines de jours suivant la complexité.

[argyronet]

<div ID="TROLL" Style="Enabled: True">

Formulaire simple : 1/4 jour homme
Formulaire moyen : 1/2 à 1 jour homme
Formulaire complexe : 1 à 3 jours homme

</div>
Tu ne parlais pas de toi, hummm ?

Par expérience, et avec un peu plus de x années d'expérience sur Access, je peux te confirmer que ce n'est pas chiffrable à prorprement parler.

Si tu te contentes de formulaires et d'états ideux, mal dimensionnés, mal dessinés etc... comme dans les comptoirs, par exemple, mais que l'application reste fonctionnelle et sans bugs, tu peux te fier à ces valeurs ci-dessus.

Pour te donner un aperçu, une appli comme les comptoirs (fournie avec Access 2000) , la concevoir telle qu'elle est prendrait quelque 3-4 jours/h...

Argy

[Tofalu]

Par expérience, et avec un peu plus de x années d'expérience sur Access, je peux te confirmer que ce n'est pas chiffrable à prorprement parler.

Si tu te contentes de formulaires et d'états ideux, mal dimensionnés, mal dessinés etc... comme dans les comptoirs, par exemple, mais que l'application reste fonctionnelle et sans bugs, tu peux te fier à ces valeurs ci-dessus.

Pour te donner un aperçu, une appli comme les comptoirs (fournie avec Access 2000) , la concevoir telle qu'elle est prendrait quelque 3-4 jours/h...

Argy

C'est pas faute d'avoir dit que ce n'était pas chiffrable. C'est d'ailleurs déjà assez difficile à chiffre avec un cahier des charges nickel alors sans ...

Donc à part donner des chiffres à la louche je ne vois guère de solution.

Quant à essayer d'isoler un élement c'est aussi difficile. Le bouton qui ouvre un état avec un filtre très complexe depuis un formulaire, c'est à mettre dans formulaire, état, module, requête ?

Si tu te contentes de formulaires et d'états ideux, mal dimensionnés, mal dessinés etc... comme dans les comptoirs, par exemple, mais que l'application reste fonctionnelle et sans bugs, tu peux te fier à ces valeurs ci-dessus.

Et c'était effectivement sur ce genre d'appli que j'ai basé mes chiffres mais en rose pas en gris

[selig]

Merci à vous 2 pour vos réponses et réactions.

Néanmoins je persiste à dire que même s'il est difficile de chiffrer, il n'est pas impossible de créer des abaques issus de l'expérience. Sinon comment faites-vous quand on vous demande combien cela va coûter ?
A l'issue de la lecture de votre cahier des charges, vous êtes capables de dires, cette application, c'est autant de formulaires (dont x simples, y complexes) et autant d'états (dont z moyens et n complexes) et là vous appliquez vos abaques.

Normalement, in fine, la charge passée est souvent très proche de la charge estimée.

Mais merci encore, je vais me baser là dessus dans 1er temps

[argyronet]

Sinon comment faites-vous quand on vous demande combien cela va coûter ?

1/ Bien pour ma part, j'ai développé il y a quelques temps déjà une DLL 100% dédiée Access/DAO avec une palanquée de fonctions embarquées et tout ce qui est imaginable au sein de celle-ci.
Je l'utilise systématiquement dans mes dev ce qui me fait gagner 30% du temps environ car je n'ai pas à réécrire les fonctions.

2/ Je réutilise aussi des modules publics déjà écrits car la structure reste quasi la même... Encore un gain de temps.

3/ Je suis très graphique et use beaucoup de photoshop pour créer les icônes, logo etc... pour le coté design mais ça, je ne le compte qu'à 50% car cela ne rentre pas vraiment en adéquation avec ce qui est en général demandé même si le résultat en vaut la chandelle.

4/ Tu ne peux pas chiffrer la coût entre quelqu'un qui débute, quelqu'un qui est à l'aise et un pro.
Je me range plutôt dans la troisième catégorie (et modeste avec ça )
Il ne faut pas confondre adaptation au CC coté fonctionnel avec analyse de ce dernier et le coté technique ou un développeur ne sait pas comment exploiter l'API TRUCMUCHE dans le contexte BIDULE avec un contrôle MACHIN...
Ce que j'essaye de te dire c'est qu'aujourd'hui, personnellement je n'apprends plus rien coté technique (avec Access, j'entends bien) et le rapport temps/coût est consacré à l'analyse du processus/résultat...
La réalisation d'un formulaire/état et du code qui l'accompagne est fluide et très rapide si tout est clair coté compréhension de ce qu'il y a à faire et ce n'est pas là dessus qu'il faut calculer le coût. Par ailleurs, un formulaire bien conçu, c'est à dire générique, fait gagner un temps considérable pour en faire un second dans le même esprit (ajout/modification d'utilisateur, de fournisseurs, de transporteurs etc...)

Imagine une application de facturation totalement opérationnelle.
Ton chef vient te voir et te demande de mettre en oeuvre l'édition d'un état statistique à l'aide d'un formulaire permettant de via une balance âgée de paramétrer les tranches par défaut 30-60-90-120-180 et plus de 180 jours, le tout en devise ou en euro au choix...

Combien va tu mettre de temps ?


Argy

[random]

Imagine une application de facturation totalement opérationnelle.
Ton chef vient te voir et te demande de mettre en oeuvre l'édition d'un état statistique à l'aide d'un formulaire permettant de via une balance âgée de paramétrer les tranches par défaut 30-60-90-120-180 et plus de 180 jours, le tout en devise ou en euro au choix...

Combien va tu mettre de temps ?


ben ca devrait pas être trop lourd
une simple table avec les tranches
une requête paramétrée (devise euro)
je reprends l'interface existant et roulez...

[selig]

Argy, je ne pense pas que nous parlions de la même chose :
Tu justifies ta réponse par rapport à ton niveau personnel sur la technique.
Moi je vais mettre en place une équipe qui n'est pas encore définie mais qui connaittront le produit avec des expériences diverses (et donc un niveau "moyen").
Par contre, avant cela il faut gagner le projet et donc l'estimer et le chiffrer.

Et c'est à ça que servent les abaques.

Sur d'autres produits comme BO ou Cognos, j'ai des abaques que nous avons construit avec notre expérience (tes points 1 à 4/) et que nous pouvons ré-utiliser sur tous nos projets.

Pour répondre à ta dernière question, je vais évaluer à la lecture du cahier des charges la complexité du formulaire et de l'état statistique demandé et je vais appliquer les abaques et je suis sur à 95 % que je vais mettre ce temps là.

Selig

[random]

si tu as des abaques bo c'est assez facile tu divises les temps par 5

[Dolphy35]

Salut,

Je rejoins Argy sur le principe.

selig :

Un abaque ce construit sur le produit, les moyens et les temps cible. Actuellement pour les moyens tu as Access, pas de fonctions générique permettant de t'alléger le codage. Pour le produit tout dépend des demandes (gestion de Stock, ERP, pilotage machines, GPAO, etc...). Pour les temps cible tu as rien et cela dépend comme dis plus haut des ressources. Pour le Formulaire proposer par Argy, je vais peut être mettre 1 J, Argy lui 1/2 J, et d'autres !! 5 min (trop fort pour nous).

Tes abaques sur les autres techno tu les as construit comment, sur RETEX je suppose et bien là c'est pareil. Tes applys ne rentreront pas toujours dans tes abaques.

Un exemple, ta première base comprend 10 formulaires compliquées à XX€, un autre client te demande une autre bdd sur le même principe tu copie les 10 formulaires et c'est combien le chiffrage ? Maintenant toujours un nouveau client qui te demande une même bdd (principe) mais qui te donne un cahier des charges graphiques et là tes formulaires sont repris pour combien ??

Le seul moyen de créer un abaque cohérent c'est retex de ton équipe et des différents outils que tu possède mais nous on ne peut pas t'aider.

Dolphy