Outils pour utilisateurs

Outils du site


slacoding

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
slacoding [2016/03/29 16:27]
admin [Modèle pour l'architecture]
slacoding [2024/04/04 15:52] (Version actuelle)
Ligne 1: Ligne 1:
-===== Développement,​ Intégration de Moodle : Engagements sur le code =====+<​html><​!-- nomoodle --></​html>​{{ :​blocks:​logo-apl.png?​nolink |}}<​html><​!-- /nomoodle --></​html>​ 
 + 
 +==== Développement,​ Intégration de Moodle : Engagements sur le code ==== 
 + 
 + 
 +===Introduction=== 
  
 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. 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.
  
-Etant 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 : +Étant ​donné les coûts significatif de la mobilisation d'​expertises diverses (conception,​ architecture,​ design, ​écriture de code et tests, 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 : 
   * Les enjeux métiers   * Les enjeux métiers
   * Les budgets mobilisables   * Les budgets mobilisables
Ligne 10: Ligne 16:
 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. 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.
  
-Edunao ​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.+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.
  
 ==== Modèle pour l'​architecture ==== ==== Modèle pour l'​architecture ====
Ligne 22: Ligne 28:
    * Améliorer l'​intégrabilité : en édifiant des contrats identifiés avec l'​extérieur de la solution, isolés dans des endroits qui ne remettent pas en question la totalité du développement à chaque modification.    * Améliorer l'​intégrabilité : en édifiant des contrats identifiés avec l'​extérieur de la solution, isolés dans des endroits qui ne remettent pas en question la totalité du développement à chaque modification.
    * Améliorer l'​évolutivité : En mettant en place les structures qui "​anticipent"​ les ajouts futurs, et rendent ces ajouts plus simples à faire.    * Améliorer l'​évolutivité : En mettant en place les structures qui "​anticipent"​ les ajouts futurs, et rendent ces ajouts plus simples à faire.
-   * Augmenter la puissance et la productivité à moyen terme : En encapsulant des fonctions (simples ou complexes) dans un "​objet"​ ou un "​composant",​ elle crée les briques de base d'un assemblage à une plus grande échelle. ​+   * Augmenter la puissance et la productivité à moyen terme : En encapsulant des fonctions (simples ou complexes) dans un "​objet"​ ou un "​composant",​ elle crée les briques de base d'un assemblage à une plus grande échelle
 +   * Organiser la séparation des intervenants techniques dans le développement (comme par exemple, séparer la logique du design visuel).
  
 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 : 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 :
Ligne 28: Ligne 35:
    * Coût d'​entretien (le coût de l'​effort de changement lorsque des modifications de l'​architecture sont décidés).    * Coût d'​entretien (le coût de l'​effort de changement lorsque des modifications de l'​architecture sont décidés).
  
-A trop forte dose, le coûts ​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é.+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é.
  
-L'examen ​à grosse maille ​des productions logicielles montre une répartition des développements dans grandes catégories : +Un examen ​rapide ​des productions logicielles montre une répartition des développements dans grandes catégories : 
  
    * **Développements sans architecture :** Le développement vise à la réalisation immédiate de l'​effet demandé, sans aucune prise en compte de sa pérennité,​ sa réutilisablité,​ son adoptabilité. On appelle souvent aussi ce type de développement du design "​jetable"​.    * **Développements sans architecture :** Le développement vise à la réalisation immédiate de l'​effet demandé, sans aucune prise en compte de sa pérennité,​ sa réutilisablité,​ son adoptabilité. On appelle souvent aussi ce type de développement du design "​jetable"​.
    * **Architecture opérationnelle :** Les principes d'​architecture sont introduits "par nécessité"​ pratique du développeur,​ qui y tire un avantage pragmatique et une réduction de l'​effort immédiat. ​    * **Architecture opérationnelle :** Les principes d'​architecture sont introduits "par nécessité"​ pratique du développeur,​ qui y tire un avantage pragmatique et une réduction de l'​effort immédiat. ​
 +   * **Architecture structurelle :** Le principes d'​architecture prennent en compte le cycle de vie à court et moyen terme de la solution et sa capacité à s'​intégrer structurellement dans l'​environnement logiciel qui l'​accueille (fourniture de services à d'​autres composants, flexibilité et configurabilité).
    * **Architecture conceptuelle :** Le développement suit des règles strictes d'​organisation dès la première ligne de code, en appliquant des règles d'​organisation systématiques,​ structurées et normatives.    * **Architecture conceptuelle :** Le développement suit des règles strictes d'​organisation dès la première ligne de code, en appliquant des règles d'​organisation systématiques,​ structurées et normatives.
  
Ligne 52: Ligne 60:
 ==== Modèle pour l'​implémentation (la réalisation technique) ==== ==== Modèle pour l'​implémentation (la réalisation technique) ====
  
 +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 : 
 +
 +   * Le projet phasé : Chaque opération suit la précédente. Chaque opération traite l'​ensemble des points fonctionnels des exigences.
 +   * Les micro-iterations : Une micro-itération engage tout ou partie (la partie accessible) des opérations de mise en œuvre dans le but de fournir en sortie un état fonctionnel (mais pas nécessairement complet) du dispositif. C'est le principe privilégié du développement agile.
  
-[[qaindex|Revenir ​à l'​index de la TMA/SLA]]+---- 
 +[[qaindex|Retour ​à l'​index ​Qualité ​de services]] - [[start|Revenir au catalogue]] - [[:​plugins|Revenir à l'​index des plugins]] 
slacoding.1459261661.txt.gz · Dernière modification: 2024/04/04 15:52 (modification externe)