Le développement dans un environnement applicatif complexe et ouvert permet de très nombreuses opportunités d'évolution, amélioration, adaptation. Il permet au client d'obtenir de l'application qu'elle converge petit à petit vers sa propre définition du modèle métier.
Étant donné les coûts significatif de la mobilisation d'expertises diverses (conception, architecture, design, coding et testing, qualité et packaging) et les enjeux parfois importants dans le quotidien de l'exploitation des fonctionnalités, il est nécessaire de projeter ses ambitions dans un modèle crédible de niveau d'achèvement, et d'ajuster ses exigences en relation. Les injonctions de qualité pure ne sont pas de l'ordre de l'absolu. Une péréquation peut et doit être faite entre :
Si la Rolls Roice n'est pas toujours la meilleure solution de transport en fonction des circonstances, il est indispensable de pouvoir décider “en toute connaissance et transparence” du degré de finition ou d'exactitude technique demandé, selon des critères normés.
ActiveProLearn propose deux modèles de qualification de la qualité techniques des solutions développées ou intégrées. Le premier modèle s'adresse à l'architecture à la conception, le deuxième modèle s'adresse à la réalisation technique elle-même. Ces modèles sont applicables soit comme “niveau d'objectif technique” contractuel dans un contrat de développent de solution technique, soit comme “niveau d'acceptabilité” pour des composants tiers qui sont candidats pour faire partie d'une solution.
L'architecture logicielle ou encore “conception technique” regroupe les décisions d'organisation des données et des traitements qui leur sont appliqués, leur découpage “organique” et la répartition des responsabilités dans les différents “composants” de la solution.
Les objectifs de l'architecture sont :
L'architecture a toujours un coût. Et elle est toujours la contrepartie d'un gain ultérieur. Elle constitue donc un investissement. La structure de coût de l'architecture est divisée en :
A trop forte dose, le coût de l'entretien de l'architecture peut devenir plus grand que le bénéfice réellement réalisé sur le projet. Il convient donc d'être prudent sur le niveau d'architecture exigé.
Un examen rapide des productions logicielles montre une répartition des développements dans 4 grandes catégories :
Il s'agit bien entendu d'un modèle assez grossier et des variations plus fines existent entre chaque catégorie.
La deuxième approche de l'architecture adresse la répartition des “responsabilités fonctionnelles” inhérentes à tout système de traitement des données. Il s'agit de responsabilités génériques présentes dès qu'un objet technique acquière, stocke, transforme ou restitue des données et des informations.
La réalisation ou la non réalisation de ces responsabilités contribue à livrer un produit plus ou moins complet, plus ou moins capable de s'intégrer en partie ou totalement dans les processus d'usage, mais aucune des fonctionnalités n'a de prédominance sur une autre :
La réalisation technique englobe les phases d'écriture, de test unitaire, de mise au point, de design (interfaces), d'installation de la configurabilité (paramétrisation), de packaging (localisation, installeurs, publication), et enfin de documentation.
L'écriture peut faire suite à une action d'architecture (pour les fonctions nouvelles), ou directement engagée (pour des équipes ayant une forte expérience de la culture de développement de Moodle).
Les tests unitaires sont réalisés sur une instance de développement, avec des données unitaires de test (tests ALPHA).
La mise au point (ou test BETA) suppose le développement globalement achevé dans ses structures principales, et capable d'être opéré dans un environnement de données réelles. La mise au point peut reprendre des éléments de design et modifier l'écriture dans des cycles micro-itératifs de développement.
Le design consiste à reprendre, organiser et optimiser les restitutions de données et l'ergonomie de commandes (choix position, organisation et accessibilité des commandes) afin d'obtenir une expérience utilisateur satisfaisante.
La configurabilité permet d'obtenir une souplesse d'adaptation de la fonctionnalité à de variation de l'environnement ou du contexte.
Le packaging consiste à obtenir un “paquet livrable et installable”, opérationnel pour l'usager final.
La documentation consiste à écrire les instructions et communications aidant à l'appropriation de l'usage par les usagers finaux.
Toutes ces opérations peuvent être cadencées selon deux grand modèles :
Retour à l'index Qualité de services - Revenir au catalogue - Revenir à l'index des plugins