Plan - Le standard "généralités" - Informations nécessaires à l'estimation - Les prémices du calcul du temps de développement - Le calcul - Options supplémentaires - petit exercice 4D Université «Estimation du temps de travail sur une application 4D» En interne ou en externe: même combat savoir estimer le plus précisément possible auprès de son client ou son responsable interne (appelé par la suite «client») le temps de travail nécessaire car - La décision est basée sur cela - Le prix est basé sur cela Les informations nécessaires à l'estimation «Well begun is half done» (en anglais, cela fait plus «in» car malgré que je sois Arlésien je ne sais pas le dire en Provencau) Pour bien estimer le projet il faut se poser les questions suivantes : - Ai-je parlé aux bons interlocuteurs? faire autant de réunions que nécessaire avec les différentes personnes concernées par le projet. Ne négligez pas les utilisateurs. - Déterminer son niveau, son envie de coopération, sa bonne volonté pour tempérer ses demandes, son degré d urgence, voir son budget. - Questionnez sur l objectif de l application, sur l existant, sur les raisons du changement. - Dois-je réaliser une application monoposte monoprocess ou multilposte, multiprocess? car une application multiprocess ou multiposte c est sensiblement la même difficulté (verrouillage des enregistrements) - Combien «d objets» déjà développés puis-je réutiliser? (Noyau de programmation, voir les nouveaux composants en 6.7) - Dois-je intégrer des «plugin» ACI(Write, Calc, 4D Open ) ou d autres (ITK..)?
- Quelle version de 4D utiliser? (la dernière, la suivante ) (Niveau de stabilité (4D forum )) - Choix de la plate-forme (Mac, Windows, via navigateur) - Taille du projet (Nombre de services impliqués, nombre d installations (sites), nombre d utilisateurs, volumes des données ) - Circulation des données (synchronisation des différents sites (ou applications du même site) en temps réel, imports exports automatiques pour consolidation, vélo-processing, pas de synchronisation ) - Nombre de types d imprimantes différentes et quel est le plus petit des écrans (définition 640*480) - Avoir en main, le plus possible, de documents, de sons, de logos, des exemples, des états à gérer (choses la plus importante pour le client = son résultat) et essayer de déterminer leurs complexités. Vous n aurez jamais trop d informations. - N ai-je pas fermé les yeux sur quelque chose d important? (on verra bien, après). Si vous ressentez un malaise (pas cardiaque) approfondissez. Au plus vous décortiquez les tâches, au plus cela sera facile à estimer. Rappelez-vous que vous devez l écrire mais aussi le debugger. - Matériel mis à la disposition de l application (type OS, mémoire, capacité de stockage), taille des tuyaux de communication pour les applications multi-sites ou application utilisant Internet (bande passante ). Conseils sur le matériel (le LC c est bien mais ) - Le client peut vouloir des changements après l estimation. Comment les intégrer? (strict ou souple? ) Les prémices du calcul Lors de la première rencontre, il y a 4 mots clés : Observer, demander, écouter & prendre des notes mais surtout en dire «le moins possible» jusqu à ce que sachiez exactement le temps de travail nécessaire. Lors de votre proposition, faites un dessin simplifié de votre structure en insistant sur les points les plus délicats de l application. N oubliez pas de laisser des choix à vos interlocuteurs sous forme d option (avec ou sans source, formulaire joli ou correct, ) en leur rappelant le coût de chaque option.
4 grandes familles d application de gestion des données - Traditionnelle (pas d utilisation d Internet, pas d échange d information automatisée ) - EDI (un peu ou pas d Internet, automatisation des échanges d informations fournisseurclient) - ecommerce (utilisation d'internet, site web pour commercial & marketing, beaucoup d échange via email ) - ebusiness (basé autour d Internet, implémentation de l EDI et ecommerce, base orienté vers le client (navigateur Web)). Dès que l on parle d Internet (ou intranet) 3 choses doivent être toujours présentes à l esprit - Le nombre de formulaire «Web» nécessitant de nombreux contrôles de saisie (tout le monde saisi, pas seulement des utilisateurs formés (à part en intranet)). De plus, un formulaire bien pour un client 4D est rarement adapté à un client Internet (à part les formulaires très simples). - Le délai de transmission du formulaire. Rien ne sert de faire un formulaire trop lourd car il risque de ne plus être consulté. Un internaute est avant tout un «surfer». - Le «poids» des animations (java ou autres) car elles sont très gourmandes en temps de développement (a chacun son métier. Des infographistes sont aussi là pour cela) Le calcul du temps de développement Petite méthode permettant rapidement de se faire une idée sur le temps de développement d une application 4D (basée sur un nombre d objet avec un paramètre). Elle n est pas infaillible, pas universelle, demande d être ajustée par rapport au niveau du développeur mais elle permet rapidement d estimer la charge de travail. Une «table standard» (je ne tiens pas compte ici des tables de programmes compteur, enumérés ) à informatiser est composé d une dizaine d objets qui sont : - La définition de la structure de la table (1 objet) - Un formulaire de saisie et sa méthode formulaire (2 objets) - Un formulaire de liste à l écran et sa méthode formulaire (2 objets) - Un formulaire d impression liste simple - Un formulaire d impression d enregistrement complet
- Un formulaire de recherche et sa méthode formulaire (2 objets) - Une methode de gestion de la table (ajouter, modifier, supprimer, editer ) (1 objet) Soit 10 objets, auxquels, il faut bien sûr ajouter, suivant le cas, une méthode d initialisation (valeurs par défaut, mise à jour des compteurs, ) une méthode de validation (mise à jour des enregistrements liés, ), un trigger, des scripts particuliers (doublons, chargement des tables reliés, calcul des totaux ), d autres éditions, soit autant d objets que nécessitent l exploitation de l application. Il est aussi évident qu un formulaire très complexe peut «coûter» pour 2 ou 3 objets. (cas d une impression difficile de facture sur papier préimprimé via des impressions lignes) En ce qui concerne les formulaires «Web», mon expérience m a appris à multiplier par «2 ou 3 suivant leur degré de complexité» le nombre d objets, sans compter les animations. Bien sûr, si vous vous servez des formulaires de 4D pour les utiliser tel quel en HTML (via leur traduction automatique en 4D) par exemple les formulaires listes, les dialogues ou les formulaires de saisie simples, ils ne doivent pas être considérés comme des formulaires «Web» Il vous suffit alors de faire la même chose pour les différentes tables de votre structure en excluant les tables de programmation et en excluant aussi les «sous-tables ou tables incluses» (ex : Factures lignes) qui n en font qu une. Vous obtenez alors un nombre d objets. 2 options - Jolie ou correcte. En sachant que l on passe environ 45 % du temps à dessiner des formulaires cela à une grande incidence sur le temps de développement de l application. Si jolie (au pixel près, redimensionnable, splitter, drag and drop, liste hierachique ) +20 %. Bien sûr il existe de plus en plus d assistant pour la génération des formulaires et la nouvelle notion d héritage de la 6.7, reste qu un client (ou un développeur) est unique et nécessite donc des particularités qu aucun n assistant ne peut entièrement apporté. - Petite application (-100 objets) + 20%, Moyenne (-300 objets) +10% sinon 0% car pour moi une application = une source d ennui de +. Je pénalise donc les petites applications. Vous obtenez alors un nombre d objets. Reste à savoir combien d objets vous êtes capable de faire par jour. Pour donner une estimation cela se situe entre 5 (débutant) & 20 objets (expert). Je sais très bien que même un expert met quelquefois 1 jour (ou +) pour faire marcher un objet particulièrement difficile, mais en moyenne
Options supplémentaires = temps supplémentaire Vous obtenez un nombre de jours bruts qui correspond au temps de développement strictosensus. Ensuite vous pouvez imaginer autant d options que vous le souhaitez - Documentation technique (facile avec l insider). Peut être aussi très complexe suivant les demandes. - Documentation utilisateur (nous sommes, à mon avis les plus mal placés pour la faire, car pour nous, notre application est intuitive, alors que pour l utilisateur elle paraît parfois, disons, plus secrète. - Installation c est à mon avis un poste gratuit car le fait de mal «installer l application ( mauvais paramétres mémoire, versions non homogènes, mauvaise installation du log de 4D backup ) nous retombe vite dessus. - L administration est souvent un poste négligeable sous 4D, tellement elle est transparente. - La garantie doit être rassurante pour le ou les décideurs (à mon avis 3 mois à 1 an à partir du jour de livraison complète du programme). Elle englobe la maintenance de l application (correction des bugs, minimes évolutions ). Par contre, la maintenance, ainsi que la récupération des données (pour récupérer l antécédent) doivent être facturée à façon (x francs / jour). Reste une dernière question pour les développeurs externes. Avec ou sans source. A mon avis faites tout pour vendre vos sources ( pas de procès, client plus libre, pas de parano aigu ) en dehors des applications éditées. Mais faites les payer (avec source = +20 %) et prévoyer une clause de propriété Petit exemple à évaluer ensemble & conclusions.