Edifice : processus eXtr me

2. Edifice : processus eXtr�me ? Le constat Les principes Le processus Edifice Edifice : un processus eXtr�me ?

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� d�croissante des SI d'�voluer : de plus en plus d'applications, de flux d�informations, d�acc�s donn�s aux utilisateurs (internes ou externes) Les utilisateurs sont rarement satisfaits de la capacit� des informaticiens � ma�triser le d�veloppement et la maintenance de leurs syst�mes d'information. Les principaux motifs de m�contentement sont les suivants : Les d�lais de d�veloppement 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 p�riodes de changement. Les d�penses 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 d�veloppement international. La capacit� d�croissante d'�voluer au sein de syst�mes d'information qui accueillent de plus en plus d'applications, ce qui les rigidifie progressivement. Les syst�mes r�alis�s de fa�on traditionnelle sont incapables de faire face � ce challenge, parce que leur int�grit� est remise en question par chacun de ces changements. Les rem�des actuels ne suffisent pas car malgr� toute l'�nergie qu'ils d�pensent et les moyens mis � leur disposition, les informaticiens n'arrivent pas � satisfaire la demande et se trouvent en situation d�fensive au sein de l'entreprise, oblig�s de justifier en permanence leurs d�passements de d�lais ou leurs d�penses. Les utilisateurs sont rarement satisfaits de la capacit� des informaticiens � ma�triser le d�veloppement et la maintenance de leurs syst�mes d'information. Les principaux motifs de m�contentement sont les suivants : Les d�lais de d�veloppement 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 p�riodes de changement. Les d�penses 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 d�veloppement international. La capacit� d�croissante d'�voluer au sein de syst�mes d'information qui accueillent de plus en plus d'applications, ce qui les rigidifie progressivement. Les syst�mes r�alis�s de fa�on traditionnelle sont incapables de faire face � ce challenge, parce que leur int�grit� est remise en question par chacun de ces changements. Les rem�des actuels ne suffisent pas car malgr� toute l'�nergie qu'ils d�pensent et les moyens mis � leur disposition, les informaticiens n'arrivent pas � satisfaire la demande et se trouvent en situation d�fensive au sein de l'entreprise, oblig�s de justifier en permanence leurs d�passements de d�lais ou leurs d�penses.

4. Les besoins des entreprises Faire �voluer le SI L�ouvrir � l�ext�rieur (clients, partenaires, fournisseurs) Am�liorer son �volutivit� (technique et organisation) Am�liorer sa fiabilit� R�duire les co�ts de maintenance, de fabrication Mutualiser les services offerts par le SI Fournir aux �quipes informatiques les moyens de r�pondre � la demande des utilisateurs Fournir aux utilisateurs des services conformes � leurs besoins Aider les utilisateurs � d�finir leurs besoins Favoriser la convergence vers une solution Rendre les �quipes informatiques plus r�actives 3 types de besoins : Am�liorer le SI => urbanisme, EAI Diminuer le co�t de sa maintenance Am�liorer le service aux utilisateurs3 types de besoins : Am�liorer le SI => urbanisme, EAI Diminuer le co�t de sa maintenance Am�liorer le service aux utilisateurs

5. La r�ponse Edifice Il y a 10 ans, fort des diverses exp�riences au sein des services des grandes entreprises, Lyon Consultants (devenu CGI France depuis) d�cide de formaliser une approche pour tenter de r�soudre ce paradoxe L�approche est mise en �uvre sur de nombreux projets, de 500 � 5000 j*h, et est maintenant formalis�e au sein d�un processus de fabrication de logiciel

6. La r�ponse Edifice Trouver un juste �quilibre entre autonomie / r�activit� et rigueur / processus Converger vers la solution gr�ce � des it�rations de fabrication Impliquer les utilisateurs dans la fabrication du logiciel Livrer r�guli�rement du logiciel R�utiliser Dissocier l�architecture et les composants applicatifs Se rendre ind�pendant des �volutions Les principes sont d�taill�s dans les slides qui suiventLes principes sont d�taill�s dans les slides qui suivent

7. Fabriquer de mani�re it�rative Pour converger vers la solution Pour r�duire les risques(technique, d�lais, organisation, �) Pour favoriser les changements Pour motiver les �quipes (utilisateurs et informaticiens) Pour �valuer de mani�re objective l�avancement du projet Cela suppose De s�appuyer sur les �l�ments d�architecture (framework) De fournir rapidement aux utilisateurs des �l�ments concrets : prototypage (outill� avec un framework) puis livraison de logiciel D�impliquer les utilisateurs 3� principe : fabriquer de mani�re it�rative Le d�faut majeur des cycles de vie classiques ("cycle en V" par exemple) est de ne pas favoriser les changements (encha�nement des �tapes apr�s validation formelle et exhaustive des �tapes pr�c�dentes). 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 d�marche Edifice� propose d'atteindre les objectifs d'un projet gr�ce � des it�rations successives et convergentes. La convergence des it�rations est favoris�e par un prototypage �volutif via la r�utilisation de composants, et non par des �tudes pr�alables 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 d�marche. En effet, si la d�marche n'est pas expliqu�e correctement au client, celui-ci peut se sentir libre de faire �voluer ses fonctionnalit�s au gr� des it�rations. Il faut donc fixer clairement dans le contrat le contour fonctionnel connu au d�but du projet et contractualiser les �volutions intervenant lors des it�rations par des avenants. La participation (et l'implication) des utilisateurs � cette d�marche est primordiale pour sa r�ussite. Les utilisateurs doivent en effet �tre pr�sents � chaque it�ration pour exprimer leurs besoins et utiliser les prototypes ou applications qui sont fournies pour ensuite transmettre leurs retours. 3� principe : fabriquer de mani�re it�rative Le d�faut majeur des cycles de vie classiques ("cycle en V" par exemple) est de ne pas favoriser les changements (encha�nement des �tapes apr�s validation formelle et exhaustive des �tapes pr�c�dentes). 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 d�marche Edifice� propose d'atteindre les objectifs d'un projet gr�ce � des it�rations successives et convergentes. La convergence des it�rations est favoris�e par un prototypage �volutif via la r�utilisation de composants, et non par des �tudes pr�alables 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 d�marche. En effet, si la d�marche n'est pas expliqu�e correctement au client, celui-ci peut se sentir libre de faire �voluer ses fonctionnalit�s au gr� des it�rations. Il faut donc fixer clairement dans le contrat le contour fonctionnel connu au d�but du projet et contractualiser les �volutions intervenant lors des it�rations par des avenants. La participation (et l'implication) des utilisateurs � cette d�marche est primordiale pour sa r�ussite. Les utilisateurs doivent en effet �tre pr�sents � chaque it�ration pour exprimer leurs besoins et utiliser les prototypes ou applications qui sont fournies pour ensuite transmettre leurs retours.

8. Les it�rations Chaque it�ration inclut la fabrication d�un sous-ensemble des fonctions du logiciel Le contenu des diff�rentes it�rations est fix� au d�marrage du projet et revu � chaque it�ration Chaque it�ration donne lieu � un cycle complet de fabrication :analyse / conception / d�veloppement / tests / livraison interne Les utilisateurs sont impliqu�s dans chaque it�ration La livraison finale donne lieu � une int�gration globale du logiciel et � des tests exhaustifs Les risques technologiques doivent �tre lev�s au plus t�t (i.e. dans les premi�res it�rations)Les risques technologiques doivent �tre lev�s au plus t�t (i.e. dans les premi�res it�rations)

9. R�utiliser � � pour am�liorer la qualit�et la r�activit� du SI Un glossaire commun Les services existants dans le SI (progiciel, legacy, �) Des composants (techniques ou m�tier) Des normes / r�gles de conception / de d�veloppement Des mod�les de conception Des outils Un processus Premier principe d�Edifice : la r�utilisation, � tous les niveaux : Fonctionnel, utilisateurs => glossaire M�thode de travail => processus, outillage, normes, mod�les de conception (design pattern) SI existant => component mining Nouveaux d�veloppements => conception et d�veloppement Orient� Objet, composantsPremier principe d�Edifice : la r�utilisation, � tous les niveaux : Fonctionnel, utilisateurs => glossaire M�thode de travail => processus, outillage, normes, mod�les de conception (design pattern) SI existant => component mining Nouveaux d�veloppements => conception et d�veloppement Orient� Objet, composants

10. R�utiliser � La majorit� des SI sont aujourd�hui construits de mani�re monolithique : un besoin (un processus) = une application = une architecture (BD, middleware, IHM, �) Pour mutualiser et ainsi diminuer les co�ts de maintenance de l�ensemble, il faut extraire ce qui est commun, au niveau technique dans un premier temps puis au niveau m�tierLa majorit� des SI sont aujourd�hui construits de mani�re monolithique : un besoin (un processus) = une application = une architecture (BD, middleware, IHM, �) Pour mutualiser et ainsi diminuer les co�ts de maintenance de l�ensemble, il faut extraire ce qui est commun, au niveau technique dans un premier temps puis au niveau m�tier

11. Dissocier l�architecture des composants applicatifs Les applications r�utilisent les �l�ments mis � disposition par l�architecture 2� principe : L'approche architecture permet de structurer les activit�s de d�veloppement logiciel � base de composants en vue d'une r�utilisation maximale des �l�ments communs � l'effort de d�veloppement. Edifice� apporte une distinction fondamentale entre les deux couches d'un syst�me d'information qui coexistent : Celle de l'architecture d�finie comme l'ensemble des �l�ments logiciels, mat�riels et m�thodologiques que l'on peut mettre en commun dans un syst�me d'information et que les applications vont r�utiliser. L'architecture vise � satisfaire les objectifs structurels de l'entreprise (r�activit�, �volutivit�, souplesse, coh�rence, qualit� de service, etc.). Celle des applications qui r�utilisent les �l�ments de la couche d'architecture dont elles ont besoin et qui permettent de satisfaire les objectifs m�tier de l'entreprise (nouveaux produits, nouvelle organisation, nouveaux canaux de distribution, etc.). Pour les progiciels, essayer de choisir des outils ouverts et capables de s�interfacer avec le reste du SI. Si possible, choisir des progiciels conformes avec les principes d�architecture du SI (BDD, Middleware, voire langage de d�veloppement).2� principe : L'approche architecture permet de structurer les activit�s de d�veloppement logiciel � base de composants en vue d'une r�utilisation maximale des �l�ments communs � l'effort de d�veloppement. Edifice� apporte une distinction fondamentale entre les deux couches d'un syst�me d'information qui coexistent : Celle de l'architecture d�finie comme l'ensemble des �l�ments logiciels, mat�riels et m�thodologiques que l'on peut mettre en commun dans un syst�me d'information et que les applications vont r�utiliser. L'architecture vise � satisfaire les objectifs structurels de l'entreprise (r�activit�, �volutivit�, souplesse, coh�rence, qualit� de service, etc.). Celle des applications qui r�utilisent les �l�ments de la couche d'architecture dont elles ont besoin et qui permettent de satisfaire les objectifs m�tier de l'entreprise (nouveaux produits, nouvelle organisation, nouveaux canaux de distribution, etc.). Pour les progiciels, essayer de choisir des outils ouverts et capables de s�interfacer avec le reste du SI. Si possible, choisir des progiciels conformes avec les principes d�architecture du SI (BDD, Middleware, voire langage de d�veloppement).

12. Se rendre ind�pendant des �volutions Technologiques Dissocier architecture et applications Structurer le syst�me d�information en couches (techniques et m�tier)La modification d'une couche doit influer le moins possible sur le fonctionnement des autres couches Organisationnelles 4 visions du Syst�me d�InformationNe pas tout m�langer ! La technologie informatique (mat�riels, logiciels, syst�mes d'exploitation, langages de programmation, technologies de communication, etc.) est en perp�tuelle �volution. Les organisations et les moyens de production des entreprises �voluent en permanence pour am�liorer la comp�titivit�. Les syst�mes informatiques doivent faciliter ces �volutions et non les contraindre. Edifice� pr�conise (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 r�le bien d�fini. Chaque couche sera plut�t d'ordre technique (li�e � un type d'outil, par exemple acc�s aux donn�es ou interface graphique) ou fonctionnel (par exemple composants m�tier global � un domaine fonctionnel ou sp�cifique � une application). La modification d'une couche ne doit pas influer (ou le moins possible) sur le fonctionnement des autres couches. De la m�me mani�re, la conception d'un processus m�tier de l'entreprise doit �tre le moins d�pendant possible de son organisation. Un changement d'organisation doit influer le moins possible sur le processus m�tier. La technologie informatique (mat�riels, logiciels, syst�mes d'exploitation, langages de programmation, technologies de communication, etc.) est en perp�tuelle �volution. Les organisations et les moyens de production des entreprises �voluent en permanence pour am�liorer la comp�titivit�. Les syst�mes informatiques doivent faciliter ces �volutions et non les contraindre. Edifice� pr�conise (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 r�le bien d�fini. Chaque couche sera plut�t d'ordre technique (li�e � un type d'outil, par exemple acc�s aux donn�es ou interface graphique) ou fonctionnel (par exemple composants m�tier global � un domaine fonctionnel ou sp�cifique � une application). La modification d'une couche ne doit pas influer (ou le moins possible) sur le fonctionnement des autres couches. De la m�me mani�re, la conception d'un processus m�tier de l'entreprise doit �tre le moins d�pendant possible de son organisation. Un changement d'organisation doit influer le moins possible sur le processus m�tier.

13. Les 4 visions du Syst�me d�Information Se rendre ind�pendant des �volutions Afin de ne pas tout m�langer, Edifice pr�conise de bien distinguer 4 vues du Syst�me d�Information : Le fonctionnel : r�pond aux questions telles que ��Que doit faire le syst�me ?��, ��Quels services doit-on automatiser ?��Cette vue permet d�isoler les fonctions (= services m�tier) qui pourront �tre r�utilis�es L�organisationnel : r�pond aux questions telles que ��qui fait quoi ?��, ��quand�? �, ��Ou ?�� Le logiciel : r�pond aux questions telles que ��Comment informatiser les besoins exprim�s ?��, ��Quels composants r�utiliser ?��, ��Comment les r�utiliser ?�� La d�finition de configurations : r�pond aux questions telles que ��Ou installer le logiciel ?��, ��Quelle version installer ?�� Pourquoi distinguer ces 4 visions ? Distinguer ces diff�rentes visions est la cl� de la r�utilisation. Cela est n�cessaire pour extraire l'organisation, qui peut �voluer, durant l'analyse et le design des classes m�tiers. Le fait de ne pas clairement s�parer ces visions et ces concepts engendre souvent une certaine confusion qui limite, � terme, la port�e de la r�utilisation. Dans une approche traditionnelle, on assimilait souvent la vision "fonctionnelle" � la vision "logicielle" : un processus = un d�veloppement sp�cifique = une application ou cha�ne applicative. Cette approche "verticale" interdit toute nature de r�utilisation. Ainsi, de fa�on g�n�rale, si l'on d�sire mettre en place une architecture de services bas�e sur la r�utilisation, il faut veiller � ne pas confondre les processus fonctionnels et les logiciels � d�velopper : on analyse et on informatise un processus, mais on d�veloppe une classe (ou un module) en r�utilisant d'autres services ou classes d�velopp�s au pr�alable. L'�quipe d'int�gration pr�pare des configurations logicielles qui sont d�ploy�es. Enfin, l'utilisateur final ex�cute une t�che. Afin de ne pas tout m�langer, Edifice pr�conise de bien distinguer 4 vues du Syst�me d�Information : Le fonctionnel : r�pond aux questions telles que ��Que doit faire le syst�me ?��, ��Quels services doit-on automatiser ?��Cette vue permet d�isoler les fonctions (= services m�tier) qui pourront �tre r�utilis�es L�organisationnel : r�pond aux questions telles que ��qui fait quoi ?��, ��quand�? �, ��Ou ?�� Le logiciel : r�pond aux questions telles que ��Comment informatiser les besoins exprim�s ?��, ��Quels composants r�utiliser ?��, ��Comment les r�utiliser ?�� La d�finition de configurations : r�pond aux questions telles que ��Ou installer le logiciel ?��, ��Quelle version installer ?�� Pourquoi distinguer ces 4 visions ? Distinguer ces diff�rentes visions est la cl� de la r�utilisation. Cela est n�cessaire pour extraire l'organisation, qui peut �voluer, durant l'analyse et le design des classes m�tiers. Le fait de ne pas clairement s�parer ces visions et ces concepts engendre souvent une certaine confusion qui limite, � terme, la port�e de la r�utilisation. Dans une approche traditionnelle, on assimilait souvent la vision "fonctionnelle" � la vision "logicielle" : un processus = un d�veloppement sp�cifique = une application ou cha�ne applicative. Cette approche "verticale" interdit toute nature de r�utilisation. Ainsi, de fa�on g�n�rale, si l'on d�sire mettre en place une architecture de services bas�e sur la r�utilisation, il faut veiller � ne pas confondre les processus fonctionnels et les logiciels � d�velopper : on analyse et on informatise un processus, mais on d�veloppe une classe (ou un module) en r�utilisant d'autres services ou classes d�velopp�s au pr�alable. L'�quipe d'int�gration pr�pare des configurations logicielles qui sont d�ploy�es. Enfin, l'utilisateur final ex�cute une t�che.

14. Les 4 visions du Syst�me d�Information Se rendre ind�pendant des �volutions Ne pas d�tailler, trop long ! Pour info : Domaine : d�coupage fonctionnel comprenant les processus li�s fonctionnellement entre eux (m�me crit�re de d�coupage que les paquetages : le moins d�interactions possible entre les domaines, le plus possible � l�int�rieur d�un domaine) Concept : entr�e du glossaire, d�finition d�un terme, d�un �l�ment du syst�me d�information, � Certains concepts deviendront des classes m�tier Processus : description d�un ensemble d�activit�s de l�entreprise amenant � la cr�ation d�un �l�ment tangible, �. �. � La notion d�acteur (r�le) y est souvent incluse : on parle dans ce cas de workflow (cf. plus loin) Fonction : �l�ment cl� de la r�utilisation. La d�finition (l�identification) des fonctions du SI est la cl� de la mutualisation des services offerts par le SI T�che : ensemble d�actions effectu�es par un m�me acteur et laissant le SI dans un �tat stable. La t�che (r�)utilise un certain nombre de fonctions. Peut �tre interactive (transactionnelle), batch, une �dition, une interface avec un syst�me externe Workflow : encha�nement de t�ches concourant � l�ex�cution du processus R�le : acteur Unit� : organisation de l�entreprise Paquetage : �l�ment d�organisation du logiciel Classe / module : �l�ment unitaire du logiciel M�thode / service : �l�ment de code assurant un service � d�autres classes appelant ce service Composant : Unit� logicielle indivisible de services ex�cutables. Peut �tre de type IHM (composant de pr�sentation), m�tier (= services rendus par le SI => cf. web service) ou tout autre composant technique (middleware , acc�s aux donn�es, �) Configuration logicielle : Ensemble de composants logiciels pr�par� pour un type de configuration syst�me donn�Il s�agit d�un concept r�cursif. Pendant la phase de d�ploiement, chaque configuration syst�me (Ensemble mat�riel et logiciel sur lequel est lanc� un syst�me d'exploitation) dans le syst�me d�information va recevoir la configuration logicielle qui lui est adapt�eNe pas d�tailler, trop long ! Pour info : Domaine : d�coupage fonctionnel comprenant les processus li�s fonctionnellement entre eux (m�me crit�re de d�coupage que les paquetages : le moins d�interactions possible entre les domaines, le plus possible � l�int�rieur d�un domaine) Concept : entr�e du glossaire, d�finition d�un terme, d�un �l�ment du syst�me d�information, � Certains concepts deviendront des classes m�tier Processus : description d�un ensemble d�activit�s de l�entreprise amenant � la cr�ation d�un �l�ment tangible, �. �. � La notion d�acteur (r�le) y est souvent incluse : on parle dans ce cas de workflow (cf. plus loin) Fonction : �l�ment cl� de la r�utilisation. La d�finition (l�identification) des fonctions du SI est la cl� de la mutualisation des services offerts par le SI T�che : ensemble d�actions effectu�es par un m�me acteur et laissant le SI dans un �tat stable. La t�che (r�)utilise un certain nombre de fonctions. Peut �tre interactive (transactionnelle), batch, une �dition, une interface avec un syst�me externe Workflow : encha�nement de t�ches concourant � l�ex�cution du processus R�le : acteur Unit� : organisation de l�entreprise Paquetage : �l�ment d�organisation du logiciel Classe / module : �l�ment unitaire du logiciel M�thode / service : �l�ment de code assurant un service � d�autres classes appelant ce service Composant : Unit� logicielle indivisible de services ex�cutables. Peut �tre de type IHM (composant de pr�sentation), m�tier (= services rendus par le SI => cf. web service) ou tout autre composant technique (middleware , acc�s aux donn�es, �) Configuration logicielle : Ensemble de composants logiciels pr�par� pour un type de configuration syst�me donn�Il s�agit d�un concept r�cursif. Pendant la phase de d�ploiement, chaque configuration syst�me (Ensemble mat�riel et logiciel sur lequel est lanc� un syst�me d'exploitation) dans le syst�me d�information va recevoir la configuration logicielle qui lui est adapt�e

15. Edifice : un processus it�ratif formalis� Les �tapes du cycle de vie Axe temporel : d�finition�: d�di�e � l'�tude de faisabilit� d�taill�e du projet (analyse pr�alable et d�veloppement du prototype) construction�: consacr�e � la fabrication du logiciel sur la base des livrables de la phase de d�finition. d�ploiement�: destin�e � rendre le logiciel disponible et op�rationnel pour tous ses utilisateurs et ses administrateurs. �volution�: concerne toutes les activit�s de maintenance sur le logiciel d�ploy� et utilis�. Axe temporel : d�finition�: d�di�e � l'�tude de faisabilit� d�taill�e du projet (analyse pr�alable et d�veloppement du prototype) construction�: consacr�e � la fabrication du logiciel sur la base des livrables de la phase de d�finition. d�ploiement�: destin�e � rendre le logiciel disponible et op�rationnel pour tous ses utilisateurs et ses administrateurs. �volution�: concerne toutes les activit�s de maintenance sur le logiciel d�ploy� et utilis�.

16. Dimensionnement de l�effort Identification des objets � fabriquer Classes m�tier T�ches (interactives, batches, �ditions, interfaces) M�trique de dimensionnement, par type d�objet Cat�gorisation et �valuation de la complexit� Attribution d�un nombre de jours par complexit� Ajout de coefficients de pond�ration et de charges transverses Edifice : un processus it�ratif formalis� Le dimensionnement (de m�me que la planification) est effectu� plusieurs fois lors du cycle de vie d'un projet : � l'issue de la phase de d�finition, apr�s acceptation de la D�cision de Faire (i.e. lors de l'envoi d'une proposition commerciale � un client) : la charge globale du projet est calcul�e, le nombre d'it�rations est choisi. On ne conna�t que le nombre de ressources pouvant �tre affect�es au projet. au d�but de chaque it�ration, apr�s le bilan de l'it�ration pr�c�dente : on a d�cid� le contour fonctionnel pr�cis de l'it�ration, on calcule pr�cis�ment la charge de l'it�ration et on affecte les t�ches aux ressources identifi�es Principe La complexit� g�n�rale d�une application d�pend bien s�r de la complexit� des classes m�tier (concepts ou stocks) qui la composent, mais aussi et surtout du nombre et de la complexit� des fonctionnalit�s du logiciel (t�ches ou flux) qui vont les manipuler (dans un environnement objet, les t�ches sont elles-m�mes constitu�es de classes). On �value donc la complexit� des classes m�tier sans se pr�occuper de leur utilisation dans les t�ches. On �value de m�me la complexit� des fonctionnalit�s du logiciel (t�ches interactives, t�ches batch, �ditions) et des interfaces avec les syst�mes externes. Le dimensionnement (de m�me que la planification) est effectu� plusieurs fois lors du cycle de vie d'un projet : � l'issue de la phase de d�finition, apr�s acceptation de la D�cision de Faire (i.e. lors de l'envoi d'une proposition commerciale � un client) : la charge globale du projet est calcul�e, le nombre d'it�rations est choisi. On ne conna�t que le nombre de ressources pouvant �tre affect�es au projet. au d�but de chaque it�ration, apr�s le bilan de l'it�ration pr�c�dente : on a d�cid� le contour fonctionnel pr�cis de l'it�ration, on calcule pr�cis�ment la charge de l'it�ration et on affecte les t�ches aux ressources identifi�es Principe La complexit� g�n�rale d�une application d�pend bien s�r de la complexit� des classes m�tier (concepts ou stocks) qui la composent, mais aussi et surtout du nombre et de la complexit� des fonctionnalit�s du logiciel (t�ches ou flux) qui vont les manipuler (dans un environnement objet, les t�ches sont elles-m�mes constitu�es de classes). On �value donc la complexit� des classes m�tier sans se pr�occuper de leur utilisation dans les t�ches. On �value de m�me la complexit� des fonctionnalit�s du logiciel (t�ches interactives, t�ches batch, �ditions) et des interfaces avec les syst�mes externes.

17. Approche pragmatique, bas�e sur l�utilisation de frameworks techniques et / ou m�tier N�cessite une forte implication des utilisateurs Livraison r�guli�re de logiciel : prototypes techniques et/ou fonctionnels puis livraison des it�rations � � Edifice : un processus eXtr�me ? Edifice s�apparente � XP sur beaucoup de points �Edifice s�apparente � XP sur beaucoup de points �

18. � � Dans un contexte d�offre de services, de projets aux forfaits Enveloppe financi�re initiale Attention � la contractualisation des changements Dans le cadre d�une int�gration au Syst�me d�Information des entreprises Adaptation � l�organisation, aux pratiques et aux contraintes du client Prise en compte des aspects transverses de la fabrication de logiciels : pilotage, int�gration, reprise des donn�es, � Edifice : un processus eXtr�me ? mais avec des restrictions �mais avec des restrictions �

19. Edifice : quelque part entre XP et UP Edifice : un processus eXtr�me ? Edifice : entre XP (pragmatisme, it�rations r�guli�res et courtes, partage des responsabilit�s) et UP (centr�e sur les mod�les, sur l�architecture et la r�utilisation)Edifice : entre XP (pragmatisme, it�rations r�guli�res et courtes, partage des responsabilit�s) et UP (centr�e sur les mod�les, sur l�architecture et la r�utilisation)

20. Edifice : un processus eXtr�me ?

21. Exemples de mise en oeuvre Gros projets Refonte totale du SI d�un compte utilities R�f�rentiel comptable d�un op�rateur t�l�com Projets moyens Gestion du transport maritime Sites Web R�f�rencement de produits des fournisseurs du b�timent Listes de mariage