coo poo optim conclusion

    Dans un premier temps on fait la COO POO, 15 nouvelles tables paramètres et 25 tables de données permanentes sur les endroits les plus coûteux et les plus stables (les moins fluctuants). Dans un second temps, après avoir fait les colonnes et les contenus des nouvelles tables de données et de paramètres puis testé et fiabilisé dans les CTIR, on installe les 25 LOAD.

Optimisation du temps CPU:

- Le nombre de lignes de tables de données diminue   (BIS --> Bf1).

- Le nombre de colonnes de tables de données diminue (BF1 --> BD1).   

- La taille des tables de paramètres diminue         (BTI --> Bp1).

- Les contenus des bases vont être plus spécifiques,

  les tables vont être indexées d'où moins de balayages.

                                             (BD1, BD2, BD5, BD6).

- le nombre de SAVE DATA sur la nouvelle maquette diminue de 69 % au bout

  d'une étape et de 80 % au bout des 2 étapes.

- Le nombre de queries sur la nouvelle maquette diminue de 37 % au bout

  d'une étape et de 57 % au bout des 2 étapes.

- L'éxécution sera plus rapide et prendra moins de place.

Optimisation du temps de développement:

- La souplesse et l'évolutivité sera augmentée grâce à la

  réduction des zones d'intervention rapide fréquentes

  qui seront mieux balisées à l'avance. Si on doit intervenir sur

  les lectures ou les calculs, on sait où aller.

- Le logiciel gagnera en fiabilité en gagnant en modularité.

- Pour les évolutions futures, on gagne en souplesse car chaque base

  d'un folio sera spécifique, indépendante des autres folios et plus facile

  à modifier séparément.

- Chaque étape de la procédure gagnera également en indépendance et clarté.

- Le code gagnera en puissance, il suffit de modifier à un endroit

  pour qu'une modification soit répercutée à tous les endroits nécessaires.

- Les charges moyennes prévues estimées pour une grosse modification annuelle

  passent de 10 mois/h à 5 mois/h. Le paramétrage devient systématique.

Optimisation de la convivialité et de l'ergonomie.

- L'analyse organique sera simplifiée, il n'y aura plus que 4 tâches

  principales pour un état. (lecture,calcul,totaux,mise en forme).

  Chaque tâche sera séparée, rationnalisée, et faite une seule fois.

- Les tables vues par les développeurs seront simplifiées

  (en nb de lignes et nb de colonnes)                 (B19 --> BD5).

  La normalisation des méthodes, des procédures, des tables, rendra plus

  compréhensible et plus lisible chaque partie.

- Les procédures seront réduites en taille (en nb de queries et data).

- L'application décomposée en modules sera plus facilement ventilée sur les

  ressources, planifiée dans le temps et développée en parallèle.

- Le développement sera plus sûr, la vérification sur un modèle structuré

  sera plus efficace, les bugs sur des objets encapsulés seront

  moins contagieux, le dépannage sera plus rapide.

- Un débutant sur RTGE (D.A.) qui ne connait pas les procédures et les

  queries devient capable de coder les nouvelles tables paramètres

  selon les demandes de changements sur la maquette.