Onglet 2 – Application, Organisation
2.1 Niveau applicatif (règles de gestion, complexité)
La difficulté applicative correspond soit au nombre et à la complexité des règles de gestion, soit à la sophistication de la demande. Il faut, pour ce paramètre, prendre en compte une complexité globale et non la présence de règles de gestion particulièrement complexes, mais isolées qui seront définies dans l'onglet -1- Métrique à la ligne " traitements, règles de métier, couche applicative ".
Cette évaluation de la complexité est subjective, elle correspond en fait à notre propre vision d'un problème. Pour certains un problème précis est complexe alors qu'il ne le sera pas pour une personne disposant de connaissances ou d'expériences propres à lui en faciliter la résolution. Pour cette raison, il est souhaitable que l'informaticien chargé de l'évaluation envisage la complexité applicative au regard des connaissances raisonnablement prévisible de la globalité de l'équipe chargée du développement. Le RAD préconise dans le cadre d’un SWAT que l’évaluation soit effectuée par la personne ressource en planification ou par une approche collégiale de l’engagement de réalisation.
2.2 Standardisation exigée (normes)
Pour certains types d'applications (isolées et à durée de vie courte par exemple), exigez un haut niveau de normalisation est un choix coûteux et sans intérêt économique. La standardisation, le respect de normes a un coût non négligeable qui doit être modulé en fonction du ROI et de la durée de vie de l'application.
Un développeur habitué à respecter systématiquement des normes et des standards de développement pourra les mettre en œuvre sans perte de temps quelle que soit la taille de l'application. Par contre, pour un développeur ne disposant pas naturellement de ces réflexes, il faut prévoir de nombreux contrôles et travaux de corrections.
2.3 Recherche de réutilisabilité (objets)
Il faut choisir entre développer vite en respectant des contraintes stratégiques de délais ou de coûts et investir dans des objets réutilisables.
Le développement d'objets ou de composants avec pour finalité une forme de réutilisation représente un choix à la fois technique et économique. La surcouche de modélisation qu'il faut définir, ainsi que le haut niveau d'abstraction avec lequel il est nécessaire de concevoir, a pour contrepartie un coût de développement prohibitif (sauf s’il est envisagé dans une stratégie justifiée le plus souvent à long terme).
2.4 Qualité documentation utilisateur
La meilleure documentation est contextuelle. Le papier doit être réservé aux principes généraux. Le niveau de qualité de la documentation d’utilisation fait l'objet d'un choix justifié techniquement et économiquement. La qualité et la simplicité sont indispensables si l'usager est un néophyte. La concision et la complétude en regard des problèmes complexes sont nécessaires si l'utilisateur est un expert du domaine.
Le niveau et le type de la documentation d'utilisation est une affaire de spécialiste. Usuellement les développeurs sont de mauvais " documenteurs ", il est donc souhaitable de faire appel à des spécialistes de cette discipline. Une autre option est de faire rédiger le cahier des charges de l'application dans l'optique d'une documentation utilisateur par un rapporteur issu de la maîtrise d'ouvrage travaillant en partenariat avec un animateur expérimenté. Dans ce cas, les avantages en terme de délais et de budget sont de disposer simultanément et immédiatement de spécifications validées et d'une documentation adaptée.
2.5 Stabilité des spécifications (ou fiabilité)
En général les applications opérationnelles ont des spécifications relativement stables et les applications d'aide à la décision ont des spécifications fluctuantes.
La stabilisation des spécifications est un des éléments clés d'un développement réussi et performant. La compétence de l'animateur est sur ce point cruciale, particulièrement lorsque l'instabilité des exigences est liée à des relations interpersonnelles difficiles. Le rôle de l'animateur (neutre) sera alors de préciser à chaque modification le coût du changement en termes de budget et de délais. En général, la prise de conscience des interlocuteurs face à un chiffrage régulier et systématique, débouche assez rapidement sur un consensus.
2.6 Culture organisationnelle
Grande entité ou administrative ou " normalisatice "
Organisation intermédiaire ou relativement souple
Petite compagnie ou organisation évoluante ou SSCI
Mode projet " haute performance " ou activité individuelle
La culture organisationnelle de l'organisation chargée du développement est certainement le point le plus important en terme d'évaluation. De nombreuses études ont démontré des temps de développement variant dans des fourchettes allant de 1 à 50. Ce point à lui seul représente toute la problématique de l'évaluation.
2.7 Administration projet (en %)
La norme est de 15 % à 20 % de l'effort global pour les tâches transversales (gestion avancement, réunions, qualité etc.). RAD de 5 % à 10 %. Le temps consacré à l'administration de projet peut varier dans un rapport de 5% à plus de 30% suivant les exigences des instances dirigeantes. Dans le cas de l'évaluateur cette notion recouvre principalement le temps passé à l'organisation, au recrutement, à la planification, au suivi de l'engagement des ressources, au pilotage, à la production de rapports de pilotage et aux éventuels comités techniques, de suivi ou de pilotage. Sont exclus les temps passés sur les aspects techniques et fonctionnels (la préparation et la réalisation des Focus, par exemple).
La planification et l'ordonnancement de l'engagement des ressources sont la base d'une gestion de projet efficace. Bien que les projets RAD induisent des cycles plus courts que les développements classiques, le suivi nécessite une attention particulière et l'usage d'un outil spécialisé. Il doit permettre une gestion facile jusqu'au niveau le plus fin de détail (tâche/heure). Il fournit automatiquement des rapports d'avancement suffisamment complets pour satisfaire la direction qui doit apprendre à se contenter de l'essentiel.
