Outils pour utilisateurs
slacoding
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
|
slacoding [2016/03/31 15:57] 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 29: | 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 3 grandes catégories : | + | Un examen rapide des productions logicielles montre une répartition des développements dans 4 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". | ||
| Ligne 73: | Ligne 79: | ||
| * Le projet phasé : Chaque opération suit la précédente. Chaque opération traite l'ensemble des points fonctionnels des exigences. | * 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ératio engage tout ou partie (la partie accessible) des opérations de mise en oeuvre 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. | + | * 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.1459432620.txt.gz · Dernière modification: 2024/04/04 15:52 (modification externe)
