E N D
2. Edifice : processus eXtrme ?
Le constat
Les principes
Le processus Edifice
Edifice : un processus eXtrme ?
3. Le constat : une situation paradoxale
Volont croissante d'voluer au sein des entreprises : nouveaux produits, nouvelles offres commerciales, nouvelles organisations, nouveaux canaux de distribution
Capacit dcroissante des SI d'voluer : de plus en plus d'applications, de flux dinformations, daccs donns aux utilisateurs (internes ou externes) Les utilisateurs sont rarement satisfaits de la capacit des informaticiens matriser le dveloppement et la maintenance de leurs systmes d'information. Les principaux motifs de mcontentement sont les suivants :
Les dlais de dveloppement sont trop longs : il est difficile d'accompagner les volutions de l'entreprise, qu'il s'agisse d'organisation ou de gamme de produits. Au lieu d'tre une aide, l'informatique est souvent un frein au changement.
Il est impossible de tirer rapidement parti des volutions technologiques.
La qualit de service est difficile assurer, surtout pendant des priodes de changement.
Les dpenses informatiques atteignent des montants importants dont on a du mal valuer les contreparties.
Toute la difficult vient de la divergence croissante entre deux tendances contradictoires :
La volont croissante d'voluer au sein des entreprises : qu'il s'agisse de nouveaux produits, de nouvelles formes d'organisation, de nouvelles approches commerciales ou de dveloppement international.
La capacit dcroissante d'voluer au sein de systmes d'information qui accueillent de plus en plus d'applications, ce qui les rigidifie progressivement.
Les systmes raliss de faon traditionnelle sont incapables de faire face ce challenge, parce que leur intgrit est remise en question par chacun de ces changements.
Les remdes actuels ne suffisent pas car malgr toute l'nergie qu'ils dpensent et les moyens mis leur disposition, les informaticiens n'arrivent pas satisfaire la demande et se trouvent en situation dfensive au sein de l'entreprise, obligs de justifier en permanence leurs dpassements de dlais ou leurs dpenses.
Les utilisateurs sont rarement satisfaits de la capacit des informaticiens matriser le dveloppement et la maintenance de leurs systmes d'information. Les principaux motifs de mcontentement sont les suivants :
Les dlais de dveloppement sont trop longs : il est difficile d'accompagner les volutions de l'entreprise, qu'il s'agisse d'organisation ou de gamme de produits. Au lieu d'tre une aide, l'informatique est souvent un frein au changement.
Il est impossible de tirer rapidement parti des volutions technologiques.
La qualit de service est difficile assurer, surtout pendant des priodes de changement.
Les dpenses informatiques atteignent des montants importants dont on a du mal valuer les contreparties.
Toute la difficult vient de la divergence croissante entre deux tendances contradictoires :
La volont croissante d'voluer au sein des entreprises : qu'il s'agisse de nouveaux produits, de nouvelles formes d'organisation, de nouvelles approches commerciales ou de dveloppement international.
La capacit dcroissante d'voluer au sein de systmes d'information qui accueillent de plus en plus d'applications, ce qui les rigidifie progressivement.
Les systmes raliss de faon traditionnelle sont incapables de faire face ce challenge, parce que leur intgrit est remise en question par chacun de ces changements.
Les remdes actuels ne suffisent pas car malgr toute l'nergie qu'ils dpensent et les moyens mis leur disposition, les informaticiens n'arrivent pas satisfaire la demande et se trouvent en situation dfensive au sein de l'entreprise, obligs de justifier en permanence leurs dpassements de dlais ou leurs dpenses.
4. Les besoins des entreprises Faire voluer le SI
Louvrir lextrieur (clients, partenaires, fournisseurs)
Amliorer son volutivit (technique et organisation)
Amliorer sa fiabilit
Rduire les cots de maintenance, de fabrication
Mutualiser les services offerts par le SI
Fournir aux quipes informatiques les moyens de rpondre la demande des utilisateurs
Fournir aux utilisateurs des services conformes leurs besoins
Aider les utilisateurs dfinir leurs besoins
Favoriser la convergence vers une solution
Rendre les quipes informatiques plus ractives 3 types de besoins :
Amliorer le SI => urbanisme, EAI
Diminuer le cot de sa maintenance
Amliorer le service aux utilisateurs3 types de besoins :
Amliorer le SI => urbanisme, EAI
Diminuer le cot de sa maintenance
Amliorer le service aux utilisateurs
5. La rponse Edifice
Il y a 10 ans, fort des diverses expriences au sein des services des grandes entreprises, Lyon Consultants (devenu CGI France depuis) dcide de formaliser une approche pour tenter de rsoudre ce paradoxe
Lapproche est mise en uvre sur de nombreux projets, de 500 5000 j*h, et est maintenant formalise au sein dun processus de fabrication de logiciel
6. La rponse Edifice Trouver un juste quilibre entre autonomie / ractivit et rigueur / processus
Converger vers la solution grce des itrations de fabrication
Impliquer les utilisateurs dans la fabrication du logiciel
Livrer rgulirement du logiciel
Rutiliser
Dissocier larchitecture et les composants applicatifs
Se rendre indpendant des volutions Les principes sont dtaills dans les slides qui suiventLes principes sont dtaills dans les slides qui suivent
7. Fabriquer de manire itrative Pour converger vers la solution
Pour rduire les risques(technique, dlais, organisation, )
Pour favoriser les changements
Pour motiver les quipes (utilisateurs et informaticiens)
Pour valuer de manire objective lavancement du projet
Cela suppose
De sappuyer sur les lments darchitecture (framework)
De fournir rapidement aux utilisateurs des lments concrets : prototypage (outill avec un framework) puis livraison de logiciel
Dimpliquer les utilisateurs 3 principe : fabriquer de manire itrative
Le dfaut majeur des cycles de vie classiques ("cycle en V" par exemple) est de ne pas favoriser les changements (enchanement des tapes aprs validation formelle et exhaustive des tapes prcdentes). Or on sait maintenant que les besoins d'une organisation voluent de plus en plus rapidement. Il est donc vain (et dangereux) de vouloir continuer s'opposer cet tat de fait.
La dmarche Edifice propose d'atteindre les objectifs d'un projet grce des itrations successives et convergentes. La convergence des itrations est favorise par un prototypage volutif via la rutilisation de composants, et non par des tudes pralables de faisabilit et une analyse exhaustive des besoins.
Dans le cadre de projets au forfait, la principale difficult est d'arriver contractualiser ce type de dmarche. En effet, si la dmarche n'est pas explique correctement au client, celui-ci peut se sentir libre de faire voluer ses fonctionnalits au gr des itrations. Il faut donc fixer clairement dans le contrat le contour fonctionnel connu au dbut du projet et contractualiser les volutions intervenant lors des itrations par des avenants.
La participation (et l'implication) des utilisateurs cette dmarche est primordiale pour sa russite. Les utilisateurs doivent en effet tre prsents chaque itration pour exprimer leurs besoins et utiliser les prototypes ou applications qui sont fournies pour ensuite transmettre leurs retours.
3 principe : fabriquer de manire itrative
Le dfaut majeur des cycles de vie classiques ("cycle en V" par exemple) est de ne pas favoriser les changements (enchanement des tapes aprs validation formelle et exhaustive des tapes prcdentes). Or on sait maintenant que les besoins d'une organisation voluent de plus en plus rapidement. Il est donc vain (et dangereux) de vouloir continuer s'opposer cet tat de fait.
La dmarche Edifice propose d'atteindre les objectifs d'un projet grce des itrations successives et convergentes. La convergence des itrations est favorise par un prototypage volutif via la rutilisation de composants, et non par des tudes pralables de faisabilit et une analyse exhaustive des besoins.
Dans le cadre de projets au forfait, la principale difficult est d'arriver contractualiser ce type de dmarche. En effet, si la dmarche n'est pas explique correctement au client, celui-ci peut se sentir libre de faire voluer ses fonctionnalits au gr des itrations. Il faut donc fixer clairement dans le contrat le contour fonctionnel connu au dbut du projet et contractualiser les volutions intervenant lors des itrations par des avenants.
La participation (et l'implication) des utilisateurs cette dmarche est primordiale pour sa russite. Les utilisateurs doivent en effet tre prsents chaque itration pour exprimer leurs besoins et utiliser les prototypes ou applications qui sont fournies pour ensuite transmettre leurs retours.
8. Les itrations Chaque itration inclut la fabrication dun sous-ensemble des fonctions du logiciel
Le contenu des diffrentes itrations est fix au dmarrage du projet et revu chaque itration
Chaque itration donne lieu un cycle complet de fabrication :analyse / conception / dveloppement / tests / livraison interne
Les utilisateurs sont impliqus dans chaque itration
La livraison finale donne lieu une intgration globale du logiciel et des tests exhaustifs
Les risques technologiques doivent tre levs au plus tt (i.e. dans les premires itrations)Les risques technologiques doivent tre levs au plus tt (i.e. dans les premires itrations)
9. Rutiliser pour amliorer la qualitet la ractivit du SI
Un glossaire commun
Les services existants dans le SI (progiciel, legacy, )
Des composants (techniques ou mtier)
Des normes / rgles de conception / de dveloppement
Des modles de conception
Des outils
Un processus Premier principe dEdifice : la rutilisation, tous les niveaux :
Fonctionnel, utilisateurs => glossaire
Mthode de travail => processus, outillage, normes, modles de conception (design pattern)
SI existant => component mining
Nouveaux dveloppements => conception et dveloppement Orient Objet, composantsPremier principe dEdifice : la rutilisation, tous les niveaux :
Fonctionnel, utilisateurs => glossaire
Mthode de travail => processus, outillage, normes, modles de conception (design pattern)
SI existant => component mining
Nouveaux dveloppements => conception et dveloppement Orient Objet, composants
10. Rutiliser La majorit des SI sont aujourdhui construits de manire monolithique : un besoin (un processus) = une application = une architecture (BD, middleware, IHM, )
Pour mutualiser et ainsi diminuer les cots de maintenance de lensemble, il faut extraire ce qui est commun, au niveau technique dans un premier temps puis au niveau mtierLa majorit des SI sont aujourdhui construits de manire monolithique : un besoin (un processus) = une application = une architecture (BD, middleware, IHM, )
Pour mutualiser et ainsi diminuer les cots de maintenance de lensemble, il faut extraire ce qui est commun, au niveau technique dans un premier temps puis au niveau mtier
11. Dissocier larchitecture des composants applicatifs Les applications rutilisent les lments mis disposition par larchitecture 2 principe : L'approche architecture permet de structurer les activits de dveloppement logiciel base de composants en vue d'une rutilisation maximale des lments communs l'effort de dveloppement.
Edifice apporte une distinction fondamentale entre les deux couches d'un systme d'information qui coexistent :
Celle de l'architecture dfinie comme l'ensemble des lments logiciels, matriels et mthodologiques que l'on peut mettre en commun dans un systme d'information et que les applications vont rutiliser. L'architecture vise satisfaire les objectifs structurels de l'entreprise (ractivit, volutivit, souplesse, cohrence, qualit de service, etc.).
Celle des applications qui rutilisent les lments de la couche d'architecture dont elles ont besoin et qui permettent de satisfaire les objectifs mtier de l'entreprise (nouveaux produits, nouvelle organisation, nouveaux canaux de distribution, etc.).
Pour les progiciels, essayer de choisir des outils ouverts et capables de sinterfacer avec le reste du SI. Si possible, choisir des progiciels conformes avec les principes darchitecture du SI (BDD, Middleware, voire langage de dveloppement).2 principe : L'approche architecture permet de structurer les activits de dveloppement logiciel base de composants en vue d'une rutilisation maximale des lments communs l'effort de dveloppement.
Edifice apporte une distinction fondamentale entre les deux couches d'un systme d'information qui coexistent :
Celle de l'architecture dfinie comme l'ensemble des lments logiciels, matriels et mthodologiques que l'on peut mettre en commun dans un systme d'information et que les applications vont rutiliser. L'architecture vise satisfaire les objectifs structurels de l'entreprise (ractivit, volutivit, souplesse, cohrence, qualit de service, etc.).
Celle des applications qui rutilisent les lments de la couche d'architecture dont elles ont besoin et qui permettent de satisfaire les objectifs mtier de l'entreprise (nouveaux produits, nouvelle organisation, nouveaux canaux de distribution, etc.).
Pour les progiciels, essayer de choisir des outils ouverts et capables de sinterfacer avec le reste du SI. Si possible, choisir des progiciels conformes avec les principes darchitecture du SI (BDD, Middleware, voire langage de dveloppement).
12. Se rendre indpendant des volutions Technologiques
Dissocier architecture et applications
Structurer le systme dinformation en couches (techniques et mtier)La modification d'une couche doit influer le moins possible sur le fonctionnement des autres couches
Organisationnelles
4 visions du Systme dInformationNe pas tout mlanger !
La technologie informatique (matriels, logiciels, systmes d'exploitation, langages de programmation, technologies de communication, etc.) est en perptuelle volution. Les organisations et les moyens de production des entreprises voluent en permanence pour amliorer la comptitivit. Les systmes informatiques doivent faciliter ces volutions et non les contraindre.
Edifice prconise (comme d'ailleurs l'ensemble des acteurs du secteur informatique l'heure actuelle) de dissocier l'architecture d'un logiciel en plusieurs couches, chaque couche ayant un rle bien dfini. Chaque couche sera plutt d'ordre technique (lie un type d'outil, par exemple accs aux donnes ou interface graphique) ou fonctionnel (par exemple composants mtier global un domaine fonctionnel ou spcifique une application). La modification d'une couche ne doit pas influer (ou le moins possible) sur le fonctionnement des autres couches.
De la mme manire, la conception d'un processus mtier de l'entreprise doit tre le moins dpendant possible de son organisation. Un changement d'organisation doit influer le moins possible sur le processus mtier.
La technologie informatique (matriels, logiciels, systmes d'exploitation, langages de programmation, technologies de communication, etc.) est en perptuelle volution. Les organisations et les moyens de production des entreprises voluent en permanence pour amliorer la comptitivit. Les systmes informatiques doivent faciliter ces volutions et non les contraindre.
Edifice prconise (comme d'ailleurs l'ensemble des acteurs du secteur informatique l'heure actuelle) de dissocier l'architecture d'un logiciel en plusieurs couches, chaque couche ayant un rle bien dfini. Chaque couche sera plutt d'ordre technique (lie un type d'outil, par exemple accs aux donnes ou interface graphique) ou fonctionnel (par exemple composants mtier global un domaine fonctionnel ou spcifique une application). La modification d'une couche ne doit pas influer (ou le moins possible) sur le fonctionnement des autres couches.
De la mme manire, la conception d'un processus mtier de l'entreprise doit tre le moins dpendant possible de son organisation. Un changement d'organisation doit influer le moins possible sur le processus mtier.
13. Les 4 visions du Systme dInformation Se rendre indpendant des volutions Afin de ne pas tout mlanger, Edifice prconise de bien distinguer 4 vues du Systme dInformation :
Le fonctionnel : rpond aux questions telles que Que doit faire le systme ?, Quels services doit-on automatiser ?Cette vue permet disoler les fonctions (= services mtier) qui pourront tre rutilises
Lorganisationnel : rpond aux questions telles que qui fait quoi ?, quand? , Ou ?
Le logiciel : rpond aux questions telles que Comment informatiser les besoins exprims ?, Quels composants rutiliser ?, Comment les rutiliser ?
La dfinition de configurations : rpond aux questions telles que Ou installer le logiciel ?, Quelle version installer ?
Pourquoi distinguer ces 4 visions ?
Distinguer ces diffrentes visions est la cl de la rutilisation.
Cela est ncessaire pour extraire l'organisation, qui peut voluer, durant l'analyse et le design des classes mtiers.
Le fait de ne pas clairement sparer ces visions et ces concepts engendre souvent une certaine confusion qui limite, terme, la porte de la rutilisation.
Dans une approche traditionnelle, on assimilait souvent la vision "fonctionnelle" la vision "logicielle" : un processus = un dveloppement spcifique = une application ou chane applicative. Cette approche "verticale" interdit toute nature de rutilisation.
Ainsi, de faon gnrale, si l'on dsire mettre en place une architecture de services base sur la rutilisation, il faut veiller ne pas confondre les processus fonctionnels et les logiciels dvelopper : on analyse et on informatise un processus, mais on dveloppe une classe (ou un module) en rutilisant d'autres services ou classes dvelopps au pralable. L'quipe d'intgration prpare des configurations logicielles qui sont dployes. Enfin, l'utilisateur final excute une tche.
Afin de ne pas tout mlanger, Edifice prconise de bien distinguer 4 vues du Systme dInformation :
Le fonctionnel : rpond aux questions telles que Que doit faire le systme ?, Quels services doit-on automatiser ?Cette vue permet disoler les fonctions (= services mtier) qui pourront tre rutilises
Lorganisationnel : rpond aux questions telles que qui fait quoi ?, quand? , Ou ?
Le logiciel : rpond aux questions telles que Comment informatiser les besoins exprims ?, Quels composants rutiliser ?, Comment les rutiliser ?
La dfinition de configurations : rpond aux questions telles que Ou installer le logiciel ?, Quelle version installer ?
Pourquoi distinguer ces 4 visions ?
Distinguer ces diffrentes visions est la cl de la rutilisation.
Cela est ncessaire pour extraire l'organisation, qui peut voluer, durant l'analyse et le design des classes mtiers.
Le fait de ne pas clairement sparer ces visions et ces concepts engendre souvent une certaine confusion qui limite, terme, la porte de la rutilisation.
Dans une approche traditionnelle, on assimilait souvent la vision "fonctionnelle" la vision "logicielle" : un processus = un dveloppement spcifique = une application ou chane applicative. Cette approche "verticale" interdit toute nature de rutilisation.
Ainsi, de faon gnrale, si l'on dsire mettre en place une architecture de services base sur la rutilisation, il faut veiller ne pas confondre les processus fonctionnels et les logiciels dvelopper : on analyse et on informatise un processus, mais on dveloppe une classe (ou un module) en rutilisant d'autres services ou classes dvelopps au pralable. L'quipe d'intgration prpare des configurations logicielles qui sont dployes. Enfin, l'utilisateur final excute une tche.
14. Les 4 visions du Systme dInformation Se rendre indpendant des volutions Ne pas dtailler, trop long !
Pour info :
Domaine : dcoupage fonctionnel comprenant les processus lis fonctionnellement entre eux (mme critre de dcoupage que les paquetages : le moins dinteractions possible entre les domaines, le plus possible lintrieur dun domaine)
Concept : entre du glossaire, dfinition dun terme, dun lment du systme dinformation, Certains concepts deviendront des classes mtier
Processus : description dun ensemble dactivits de lentreprise amenant la cration dun lment tangible, . . La notion dacteur (rle) y est souvent incluse : on parle dans ce cas de workflow (cf. plus loin)
Fonction : lment cl de la rutilisation. La dfinition (lidentification) des fonctions du SI est la cl de la mutualisation des services offerts par le SI
Tche : ensemble dactions effectues par un mme acteur et laissant le SI dans un tat stable. La tche (r)utilise un certain nombre de fonctions. Peut tre interactive (transactionnelle), batch, une dition, une interface avec un systme externe
Workflow : enchanement de tches concourant lexcution du processus
Rle : acteur
Unit : organisation de lentreprise
Paquetage : lment dorganisation du logiciel
Classe / module : lment unitaire du logiciel
Mthode / service : lment de code assurant un service dautres classes appelant ce service
Composant : Unit logicielle indivisible de services excutables. Peut tre de type IHM (composant de prsentation), mtier (= services rendus par le SI => cf. web service) ou tout autre composant technique (middleware , accs aux donnes, )
Configuration logicielle : Ensemble de composants logiciels prpar pour un type de configuration systme donnIl sagit dun concept rcursif. Pendant la phase de dploiement, chaque configuration systme (Ensemble matriel et logiciel sur lequel est lanc un systme d'exploitation) dans le systme dinformation va recevoir la configuration logicielle qui lui est adapteNe pas dtailler, trop long !
Pour info :
Domaine : dcoupage fonctionnel comprenant les processus lis fonctionnellement entre eux (mme critre de dcoupage que les paquetages : le moins dinteractions possible entre les domaines, le plus possible lintrieur dun domaine)
Concept : entre du glossaire, dfinition dun terme, dun lment du systme dinformation, Certains concepts deviendront des classes mtier
Processus : description dun ensemble dactivits de lentreprise amenant la cration dun lment tangible, . . La notion dacteur (rle) y est souvent incluse : on parle dans ce cas de workflow (cf. plus loin)
Fonction : lment cl de la rutilisation. La dfinition (lidentification) des fonctions du SI est la cl de la mutualisation des services offerts par le SI
Tche : ensemble dactions effectues par un mme acteur et laissant le SI dans un tat stable. La tche (r)utilise un certain nombre de fonctions. Peut tre interactive (transactionnelle), batch, une dition, une interface avec un systme externe
Workflow : enchanement de tches concourant lexcution du processus
Rle : acteur
Unit : organisation de lentreprise
Paquetage : lment dorganisation du logiciel
Classe / module : lment unitaire du logiciel
Mthode / service : lment de code assurant un service dautres classes appelant ce service
Composant : Unit logicielle indivisible de services excutables. Peut tre de type IHM (composant de prsentation), mtier (= services rendus par le SI => cf. web service) ou tout autre composant technique (middleware , accs aux donnes, )
Configuration logicielle : Ensemble de composants logiciels prpar pour un type de configuration systme donnIl sagit dun concept rcursif. Pendant la phase de dploiement, chaque configuration systme (Ensemble matriel et logiciel sur lequel est lanc un systme d'exploitation) dans le systme dinformation va recevoir la configuration logicielle qui lui est adapte
15. Edifice : un processus itratif formalis Les tapes du cycle de vie Axe temporel :
dfinition: ddie l'tude de faisabilit dtaille du projet (analyse pralable et dveloppement du prototype)
construction: consacre la fabrication du logiciel sur la base des livrables de la phase de dfinition.
dploiement: destine rendre le logiciel disponible et oprationnel pour tous ses utilisateurs et ses administrateurs.
volution: concerne toutes les activits de maintenance sur le logiciel dploy et utilis.
Axe temporel :
dfinition: ddie l'tude de faisabilit dtaille du projet (analyse pralable et dveloppement du prototype)
construction: consacre la fabrication du logiciel sur la base des livrables de la phase de dfinition.
dploiement: destine rendre le logiciel disponible et oprationnel pour tous ses utilisateurs et ses administrateurs.
volution: concerne toutes les activits de maintenance sur le logiciel dploy et utilis.
16. Dimensionnement de leffort
Identification des objets fabriquer
Classes mtier
Tches (interactives, batches, ditions, interfaces)
Mtrique de dimensionnement, par type dobjet
Catgorisation et valuation de la complexit
Attribution dun nombre de jours par complexit
Ajout de coefficients de pondration et de charges transverses Edifice : un processus itratif formalis Le dimensionnement (de mme que la planification) est effectu plusieurs fois lors du cycle de vie d'un projet :
l'issue de la phase de dfinition, aprs acceptation de la Dcision de Faire (i.e. lors de l'envoi d'une proposition commerciale un client) : la charge globale du projet est calcule, le nombre d'itrations est choisi. On ne connat que le nombre de ressources pouvant tre affectes au projet.
au dbut de chaque itration, aprs le bilan de l'itration prcdente : on a dcid le contour fonctionnel prcis de l'itration, on calcule prcisment la charge de l'itration et on affecte les tches aux ressources identifies
Principe
La complexit gnrale dune application dpend bien sr de la complexit des classes mtier (concepts ou stocks) qui la composent, mais aussi et surtout du nombre et de la complexit des fonctionnalits du logiciel (tches ou flux) qui vont les manipuler (dans un environnement objet, les tches sont elles-mmes constitues de classes).
On value donc la complexit des classes mtier sans se proccuper de leur utilisation dans les tches.
On value de mme la complexit des fonctionnalits du logiciel (tches interactives, tches batch, ditions) et des interfaces avec les systmes externes.
Le dimensionnement (de mme que la planification) est effectu plusieurs fois lors du cycle de vie d'un projet :
l'issue de la phase de dfinition, aprs acceptation de la Dcision de Faire (i.e. lors de l'envoi d'une proposition commerciale un client) : la charge globale du projet est calcule, le nombre d'itrations est choisi. On ne connat que le nombre de ressources pouvant tre affectes au projet.
au dbut de chaque itration, aprs le bilan de l'itration prcdente : on a dcid le contour fonctionnel prcis de l'itration, on calcule prcisment la charge de l'itration et on affecte les tches aux ressources identifies
Principe
La complexit gnrale dune application dpend bien sr de la complexit des classes mtier (concepts ou stocks) qui la composent, mais aussi et surtout du nombre et de la complexit des fonctionnalits du logiciel (tches ou flux) qui vont les manipuler (dans un environnement objet, les tches sont elles-mmes constitues de classes).
On value donc la complexit des classes mtier sans se proccuper de leur utilisation dans les tches.
On value de mme la complexit des fonctionnalits du logiciel (tches interactives, tches batch, ditions) et des interfaces avec les systmes externes.
17. Approche pragmatique, base sur lutilisation de frameworks techniques et / ou mtier
Ncessite une forte implication des utilisateurs
Livraison rgulire de logiciel : prototypes techniques et/ou fonctionnels puis livraison des itrations
Edifice : un processus eXtrme ? Edifice sapparente XP sur beaucoup de points Edifice sapparente XP sur beaucoup de points
18.
Dans un contexte doffre de services, de projets aux forfaits
Enveloppe financire initiale
Attention la contractualisation des changements
Dans le cadre dune intgration au Systme dInformation des entreprises
Adaptation lorganisation, aux pratiques et aux contraintes du client
Prise en compte des aspects transverses de la fabrication de logiciels : pilotage, intgration, reprise des donnes, Edifice : un processus eXtrme ? mais avec des restrictions mais avec des restrictions
19. Edifice : quelque part entre XP et UP Edifice : un processus eXtrme ? Edifice : entre XP (pragmatisme, itrations rgulires et courtes, partage des responsabilits) et UP (centre sur les modles, sur larchitecture et la rutilisation)Edifice : entre XP (pragmatisme, itrations rgulires et courtes, partage des responsabilits) et UP (centre sur les modles, sur larchitecture et la rutilisation)
20. Edifice : un processus eXtrme ?
21. Exemples de mise en oeuvre Gros projets
Refonte totale du SI dun compte utilities
Rfrentiel comptable dun oprateur tlcom
Projets moyens
Gestion du transport maritime
Sites Web
Rfrencement de produits des fournisseurs du btiment
Listes de mariage