Tout développement des applications quelle que soit la méthode utilisée, se basent sur les principales phases suivantes :

1. Phase de planification
2. Phase d'analyse
3. Phase de conception
4. Phase de mise en oeuvre
5. Phase de support

Le développement de tout nouveau système d'information exige d'ordinaire trois phases :

1. La phase d'analyse : spécification des besoins sans contraintes technologiques (modèle descriptif)
2. La phase de conception : formalisation logique des solutions : architecture et la structure d'application (modèle prescriptif)
3. La phase de mise en oeuvre : construction, essais et installation d'une application

On parle aussi de deux phases supplémentaires :

1. La phase de planification : lancement et approbation.
2. La phase de support. (phase dans le cycle de vie global de l'application) : maintenance et amélioration de l'application. Cette phase est beaucoup plus longue que toutes les autres phases combinées et la plus coûteuse.

But → produire une application fiable et fonctionnelle et s'assurer que les utilisateurs sont tous bien formés.

Les activités principales :

1. Construire les composantes logicielles : écrire les programmes, l'aide de langages de programmation (comme VB.net, Java, etc) ou en utilisant les outils de développement et des composantes existantes
2. Vérifier et tester : fonctionnalités et conformité aux spécifications des besoins des utilisateurs,
3. Développer des prototypes pour la mise au point : pour vérifier les différentes stratégies d'implantation et s'assurer que l'application est au point et sera capable de traiter le volume exigé de transactions
4. Convertir les données des système existants : prend souvent la forme d'un petit projet autonome impliquant l'analyse, la conception et l'implémentation de procédure de conversion et de nettoyage (épuration) des données existantes ,
5. Former les utilisateurs et documenter le système,
6. Installer le système et l'intégrer à travers toute l'entreprise : nouveaux matériels, logiciels et bases de donnés.

But → garder l'application opérationnelle de manière productive pendant son utilisation. Pendant la phase de support, des mises à niveau et des améliorations peuvent être effectuées qui exigeront, probablement, leurs propres projets de développement.

Les activités principales :

1. Maintenir l'application : la corrections des erreurs (débogage) et l'ajustement des spécifications de traitement
2. Améliorer l'application : projet de développement de mise à niveau ( causes de changements de réglementations gouvernementales, des changement au milieu des affaires – nouveaux marchés, nouveaux concurrents, nouvelles infrastructure),
3. Soutenir les utilisateurs : support à la clientèle (assistance aux utilisateurs, formation des nouveaux utilisateurs, le maintien d'une documentation à jour).

Le processus de développement d'une application peut être observé selon deux points de vue complémentaires :

1. La vue de l'encadrement qui se préoccupe des aspects financiers, stratégiques, commerciaux et humains;
2. La vue technique qui se concentre sur l'ingénierie, le contrôle de la qualité et la méthode de modélisation.

Les deux points de vue sont synchronisés à la fin de chaque étape de développement et permettent de définir les techniques de gestion des projets.

But ou l'objectif de la gestion des projets → planifier, coordonner, diriger et surtout contrôler les ressources impliquées dans le projet de développement de SI.

Définition de la gestion de projet → méthodologie visant à faire travailler ensemble, des ressources différentes pour atteindre un but commun, qui est la livraison d'un produit ou d'un service en respectant un calendrier et un budget prédéterminés.

Intervenants dans le projet:

• Chef du projet : est une personne responsable de la gestion du projet qui doit être qualifiée, expérimentée et jouir de qualités humaines de communication. Il compose l'équipe, assure la planification des tâches de chaque intervenant, prévoit les échéanciers, coordonne les tâches, gère le budget et contrôle l'ensemble;
• Équipe du projet : groupe de personnes qui coopèrent pour atteindre un objectif commun (livraison du SI) et dont chacun est responsable d'exécuter les tâches lui étant attribuées, de produire des livrables de ces tâches et de respecter les échéanciers (analystes, architectes, programmeurs, testeurs, etc.)
• Autres ressources : matériel, techniques, outils, etc.

La gestion de projets est une forme particulière d'administration qui consiste à organiser et diriger d'autres personnes (autres membres d'équipe que le chef du projet) pour qu'elles parviennent à un résultat donné en respectant un calendrier et un budget prédéterminés.

La gestion de projet, pour être mené à bien, doit être automatisée, selon les étapes suivantes :

1. Planification de projet ;
2. Mise en œuvre de projet ;
3. Pilotage de projet (contrôle et suivi);
4. Terminaison de projet (fermeture et évaluation).

But → déterminer et estimer entièrement le travail à accomplir afin de pouvoir l'assigner aux différents membres de l'équipe (et, bien sûr, d'en connaître les coûts).

La planification est accompagnée de l'évaluation des risques, des problèmes potentiels et de l'identification des mesures d'urgence ou correctives à appliquer.

La planification est cruciale :

• Parce que les projets sont soumis à des contraintes de temps et d'argent et qu'ils ont une nature ponctuelle;
• Parce qu'elle permet d'éliminer ou de réduire l'incertitude, d'améliorer l'efficacité, d'aider à obtenir une compréhension claire du projet, d'établir une base de référence pour le suivi et le contrôle.

Bref, « si vous omettez la planification, vous planifiez d'échouer ».

Les activités de la planification sont les suivantes :

1. Définir le mandat du projet et établir les objectifs du projet;
2. Établir, analyser et découper les tâches à accomplir;
3. Identifier les responsabilités du personnel et des ressources;
4. Établir l'échéancier de chaque activité;
5. Estimer les coûts;

Les niveaux de planification sont les suivants :

• Stratégique (définition du mandat (contrat) et d'envergure du projet – “commande” au chef du projet);
• Tactique (développement du plan global (en équipe) pour le projet entier; outils : diagramme de Gantt – pour élaborer l'échéancier, CPM (Critical Path Method) – pour établir le chemin critique);
• Opérationnelle (préparation des plans détaillés (2 à 3 mois), affectation des ressources humaines; outils : matrices de responsabilités).

Remarques :

1. Lors de la planification du projet, la prévision est une tâche délicate, où le chef de projet, doit estimer des délais et des coûts, avec une marge d'erreur acceptable. De mauvaises prévisions entraînent un dépassement important des délais et du coût du budget, qui peut être catastrophique et impliquer dans certains cas l'abandon du projet. Il existe de 2 façons de faire pour émettre des prévisions :
   • Se baser sur les projets antérieurs de même calibre, et procéder par analogie ;
   • Faire une estimation de bas en haut ou Bottum-Up (estimer d'abord les tâches, puis remonter aux activités). L'estimation des coûts suit celle des délais, en considérant entre autres, les taux horaires des employés impliqués, les coûts du materiel requis, etc.
2. Pour les projets de développement avec CVL itératif et incrémental, il faut planifier des itérations. Il n'y a pas de réponse toute faite pour ça. Pour un projet de dix-huit mois environ, il y aura entre 3 et 6 itérations. Les itérations ont toutes à peu près la même durée. La première itération est la plus difficile à planifier car elle demande la mise en place de l'ensemble de l'environnement de développement et de l'équipe. On ne planifie que l'itération suivante (planification adaptative et non prédictive).

But → développer et communiquer le plan global du travail.

Les activités de la mise en œuvre du projet sont les suivantes :

• Choisir le logiciel de gestion de projet (Microsoft Project, par exemple);
• Créer le fichier de gestion de projet (plan global de projet);
• Saisir toutes les tâches du projet en précisant la hiérarchie des taches, leur durée, etc… (développer une structure de répartition du travail (SRT) qui est une hiérarchie de toutes les tâches individuelles nécessaires à la complétion du projet);
• Répartir des ressources humaines et matérielles aux tâches;
• Saisir des coûts.

But → mesurer, évaluer et prendre des mesures correctives si et lorsque requis afin d'assurer le succès du projet.

Un aspect critique du contrôle et suivie de projets est la gestion de changements.

• Mesurer qui consiste à déterminer quel est le progrès réalisé envers les résultats attendus en termes de temps et d'argent;
• Évaluer qui consiste à établir les causes des écarts par rapport au plan de projet et à identifier les mesures correctives possibles;
• Prendre des mesures correctives qui consiste à agir de manière à corriger les déficiences et à prendre avantage des situations favorables.

• Assignation d'un officier de contrôle de projet afin de former les chargés d'équipe sur les méthodes, les outils, les procédures, de discuter de la progression et des mesures correctives, etc.
• Revues générales de projet;
• Répétition structurées;
• Rencontres de l'équipe de projet;
• Entrevues individuelles;
• Communication informelle (MBWA – Management By Walking Arround).

• Suivi (contrôle) opérationnel : évaluer ce qui a été fait versus ce qui reste à faire pour identifier les écarts et prendre les mesures correctives (feuilles de temps, valeur acquise, gestionnaire baladeur, assurance et contrôle de la qualité, feedback du client (s'il est exposé aux résultats), revues d'équipe);
• Suivi (contrôle) tactique : évaluer ce qui a été accompli par rapport à ce qui avait été planifié au niveau du plan global (littéralement la somme de tous suivis du niveau opérationnel)( rencontres régulières du comité de projet – chef de projet et chefs d'équipes);
• Suivi (contrôle) stratégique : évaluer ce qui a été accompli par rapport au mandat et à la mission du chef de projet (rencontres mensuelles du comité de direction).

But → obtenir l'acceptation par le client des résultats du projet qui implique que le client confirme que des paramètres qualitatifs et quantitatifs du projet ont été rencontrés, après correction des anomalies et l'inspection finale.

Lorsque l'approbation du client est obtenue, le projet entre dans sa phase de fermeture, d'évaluation et de démantèlement qui signifie :

• Remettre les résultats (logiciel et documentation) dans les mains de ceux qui en feront l'exploitation et l'entretien;
• Réaffecter le personnel, effectuer l'évaluation de performance et obtenir le feed-back;
• Écrire le rapport du projet qui va être archivé afin de servir aux projets futurs : synopsis du projet, son déroulement, les leçons apprises , les recommandations d'amélioration;
• Résoudre les réclamations et revendications;
• Disposer les fournitures, équipements et installations restantes.

• Compréhension de l'objectif d'affaire (pas d'objectifs vagues);
• Concentration constante sur les résultats;
• Définition claire de l'envergure (pour ne pas manquer de ressources essentielles);
• Vision globale de comment le projet sera réalisé;
• Compréhension des risques et leur gestion;
• Gestion des changements avec rigueur ;
• Établissement d'une structure bien définie (de bons canaux de communication internes et externes; décisions, rôles et responsabilités);
• Planification méticuleuse et détaillée;
• Motivation des membres de l'équipe soutien technique, implication des utilisateurs).

• Mandat approuvé et publié;
• Plan global pour l'ensemble du projet;
• Plan détaillé pour les prochains 2-3 mois;
• Le chef du projet sait ce qui est terminé et ce qui reste à faire;
• Chaque membre d'équipe sait ce qu'il a à faire pour les prochaine 2-3 semaines, croît qu'il peut le faire et se dévoue à le faire;
• Forte implication des utilisateurs ;
• Il n'y a pas de problème que le chef de projet ignore;
• Un processus de suivi des demandes de changement est établi, connu et utilisé;
• Des mécanismes de résolution de problèmes sont définis, connus et utilisés.

But ou l'objectif → offrir un produit ou un service de qualité, au bon endroit, au bon moment, à la bonne personne et au meilleur prix.

Pour atteindre ces objectifs, il est indispensable de :

1. Documenter le projet ainsi que ses livrables de manière à faciliter la visibilité et la communication des tâches et des produits
2. Utiliser des standards afin de réaliser les tâches et les documenter :
   • Les standards internationaux externes à l'entreprise (ISO (International Organization for Standardization), IEC(International Electrotechnical Commision), ANSI (American National Standards Institute), IEEE (Institute of Electrical and Electronics Engineers) );
   • Les standards internes (normes internes) définis par l'entreprise.

La qualité d'un logiciel n'est pas l'absence d'erreurs uniquement. La qualité d'un logiciel est son aptitude à satisfaire tous les besoins des utilisateurs. Un logiciel sera donc de bonne qualité uniquement s'il est développé par une méthode rigoureuse assurant un produit conforme aux besoins des utilisateurs.

Il existe des normes qui permettent aux entreprises de :

• Mettre en œuvre des méthodes de travail adaptées à leurs travaux ;
• D'être certifiées et donc reconnues comme entreprises intégrant la qualité dans leur fonctionnement.

En génie logiciel divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui dépendent, entre autres, du domaine de l'application et des outils utilisés. Les facteurs peuvent être classés en internes (visibles par les développeurs) et externes (visibles par les utilisateurs). Parmi ces derniers nous retiendrons :

• Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications.
• Fiabilité (ou robustesse) : aptitude d'un produit logiciel à fonctionner dans des conditions anormales.
• Extensibilité : facilité avec laquelle un logiciel se prête à une modification ou à une extension des fonctions qui lui sont demandées.
• Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications.
• Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels.
• Efficacité : Utilisation optimale des ressources matérielles.
• Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements matériels et logiciels.
• Vérifiabilité : facilité de préparation des procédures de test.
• Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non autorisés.
• Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.

Insuffisance de qualité mène à :

• Pertes en productivité;
• Pertes en revenus.

Selon le standard ISO/IEC 9126, la qualité d'une application logicielle est évaluée par :

• Fonctionnalité (validité);
• Fiabilité;
• Utilisabilité;
• Rendement;
• Maintenabilité;
• Portabilité.

Assurance qualité consiste à s'assurer que chaque ressource sait exactement et à l'avance ce qu'il a à faire et comment.

Contrôle de la qualité consiste à faire des revues de contrôle ou y assister pour aider à évaluer la qualité des biens livrables, la communication entre les parties, le niveau d'engagement, la quantité et le niveau des mesures correctives à adapter; à s'assurer que les normes sont respectées et que les besoins du client sont rencontrés;

Le développement d'un système d'information doit livrer un produit (SI) à la fin du projet de développement. Pour que le projet et le produit obtenu soient de bonne qualité, il est impératif de suivre des standards.

• Est une norme ou consensus élaboré par des experts dans le but d'unifier le langage et les façons de faire dans un domaine donné
• Les standards sont accessibles sous forme de rapports et de guides
• Les standards internationaux sont élaborés par des experts du domaine organisés en groupes de travail, puis approuvés par des organismes spécialisés tels que ISO, IEEE.
• Les standards sont régulièrement revus et améliorés.

• Faire profiter de l'expertise existante
• Éviter de réinventer la roue
• Offrir les meilleures pratiques
• Permettre la visibilité des tâches et produits
• Faciliter la communication du savoir et savoir-faire
• Sauvegarder temps et argent

Les standards relatifs au développement des SI ont été au départ exclusivement militaires (US), puis mis à la disposition de la communauté internationale. Il existe actuellement toute une myriade de standards ISO/IEEE ayant trait avec les technologies de l'information (International Standards Organisation (ISO), Institute of Electrical and Electronic Engineering (IEEE)).

Les standards IEEE sont notés généralement IEEE Std XXXX.DDDD où XXXX est le numéro du standard et DDDD est l'année de référence.

Les standards les plus essentiels sont :

1. standard des processus de cycle de vie;
2. standard des plans de projet (SPMP);
3. standard des spécifications de l'analyse (SRS);
4. standard de la conception (SDD).

Noté IEEE/EIA Std 12207, le standard de cycle de vie considère tout le cycle de vie d'un SI sous forme de processus. Il indique pour chacune des activités des processus, un ensemble de tâches standards à respecter. Les processus répertoriés par ce standard sont :

1. Processus primaires
2. Acquisition
3. Approvisionnement
4. Développement
5. Opération
6. Maintenance
7. Processus de support
8. Documentation
9. Gestion des versions
10. Assurance qualité
11. Vérification
12. Validation
13. Revue jointe
14. Audit
15. Résolution de problèmes
16. Processus organisationnels
17. Management
18. Infrastructure
19. Amélioration
20. Formation

Le standard des plans de projets (Software Project Management Plan (SPMP)), noté IEEE Std 1058, est conçu pour les chefs du projet (planification et suivi) et permet de :

1. déterminer les plans de gestion du projet de développement
2. décrire tous les aspects de planification du projet, de manière quasi-complète
3. couvrir les aspects tels que :
4. contexte du projet;
5. échéancier;
6. personnel impliqué;
7. ressources matérielles et logicielles;
8. gestion des versions, du risque, vérifications et validation, maintenance, etc.

Le SPMP propose le plan suivant pour la planification des projets, englobant ainsi de manière quasi-complète, tous les aspects d'un projet de développement de SI.

Document avec le plan standard SPMP

Le standard des spécifications de l'analyse (SRS - Software Requirement Specifications), noté IEEE Std 830, décrit toutes les clauses de l'étape d'analyse et ses spécifications. Un plan standard est proposé, sorte d'aide-mémoire avec toutes les clauses qui doivent apparaître dans un document livré à la fin de l'étape d'analyse.

Le standard de la conception (SDD - Software Design Description), noté IEEE Std 1016, décrit toutes les clauses de l'étape de conception et ses spécifications. Plusieurs plans standards sont proposés pour documenter cette étape, en fonction de l'approche de conception utilisée.

Une organisation soucieuse de la qualité de ses projets et produits implante et fait respecter les standards par tous ses employés impliqués.

Les standards qui ne sont pas créés par l'organisation mais plutôt importés de l'extérieur sont appelés des standards ou normes externes. Ce sont généralement les standards internationaux, et sont stables (ne changent pas très fréquemment).

Les standards développés au sein de l'organisation, et donc propres à celle-ci sont appelés des standards ou normes internes. Ce sont le plus souvent des choix que l'organisation fait pour les outils, techniques, méthodes, nomenclature, etc. (exemple : langages de programmation utilisés, méthodes de conception, nomenclature des fichiers, nomenclature des adresses emails, etc.). On dit que ce sont des standards de bas niveau, ce sont ceux qui peuvent changer plus fréquemment.

Les standards internes :

1. Sont des normes internes à l'entreprise
2. Complètent les standards internationaux
3. Spécifient les méthodes, techniques, outils, langages spécifiques adoptés par l'entreprise
4. Sont toujours cités ou référencés dans le SPMP
5. Sont documentés sous forme de rapports internes.

Les standards qui sont lourds à implanter la première fois, assurent:

1. la qualité du projet et de l'entreprise;
2. l'efficacité extraordinaire de gestion des projets;
3. l'indépendance du facteur humain;
4. le savoir-faire et savoir-faire documenter, sauvegardé et archivé;
5. la communication et visibilité aisées.

L'adoption des technologies objet n'implique pas obligatoirement de revoir les procédures de développement en place. Néanmoins, pour réellement bénéficier de l'approche objet, il consiste à établir une solution totalement objet.

Il n'existe pas une forme de processus de développement adaptée à tous les projets, tous les domaines d'application et toutes les cultures d'entreprises.

La première moitié des années 90 a vu apparaître une cinquantaine de méthodes objet. Les grands traits des objets, repris par de nombreuses méthodes, s'articulent autour des notions de classes, d'association (décrite par James Rumbaugh), de partition en sous-système (Grady Booch) et autour de l'expression des besoins à partir de l'étude de l'interaction entre l'utilisateur et le système (les cas d'utilisation d'Ivar Jacobson).

1. offrent la stabilité de la modélisation par rapport aux entités du monde réel;
2. utilisent le modèle assez simple qui faut appel à seulement 5 concepts fondateurs : objets, messages, classes, généralisation, polymorphisme, pour exprimer de manière uniforme l'analyse, la conception et la réalisation d'un SI;
3. permettent la réutilisation des éléments;
4. permettent l'unification des approches cartésiennes (le système fait) et approches systémiques (le système est – totalité organisée, dont les éléments ne peuvent être définis que les uns par rapports aux autres);
5. facilitent la décomposition / recomposition et permettent la construction du complexe à partir de l'élémentaire avec l'intégration statique et dynamique des composants du système;
6. établissent la correspondance entre espace problème (analyse) et espace solution (conception/réalisation).

Les méthodes structurées (approches traditionnelle) reposent sur:

1. Modélisation des données;
2. Modélisation des traitements;
3. Synchronisation (validation) données et traitements.

L'architecture logicielle est le reflet des fonctions du système, et les évolutions fonctionnelles peuvent impliquer des modifications structurelles lourdes (couplage statique entre architecture et fonctions).

Les méthodes objet (approche objet) reposent sur :

1. Association des données et des traitements dans une même entité un objet logiciel.

Un objet contient des données (attributs) et des traitements (méthodes).

1. Encapsulation masquant les données et traitements internes : l'interface de l'objet est le point du contact avec l'extérieur et les attributs d'un objet ne sont accessibles que par les méthodes qui implémentent l'interface.
2. Niveau abstrait de manipulation des entités à base de classe et un niveau concret à base d'instance.
3. Identification de chaque instance.
4. Niveaux d'accès aux données et traitements (publique, privé,..).
5. Séparation des interfaces de manipulation de l'implémentation des traitements.
6. Mécanisme d'héritage (généralisation et spécialisation).
7. Polymorphisme : l'interprétation particulière des messages d'un objet émetteur par un objet destinataire

Dans l'architecture logicielle les fonctions se présentent par des formes de collaboration entre les objets qui composent le système et les évolutions fonctionnelles ne remettent plus en cause la structure statique du SI (couplage dynamique entre architecture et fonctions).

Le Processus Unifié (PU) (1999) est un processus de développement (méthode qui permet de construire, réaliser et éventuellement maintenir un logiciel) itératif et incrémental de SI orienté objet. Le RUP (Rational Unified Process) est sa forme élaborée et détaillée. Ici, le terme processus est synonyme de méthode (méthodologie).

1. il utilise le CVL itératif et incrémental avec les itérations courtes et de durée fixe :
2. traitement des questions importantes ou très risquées dans les premières itérations (piloté par l'analyse des risques);
3. implication permanente des utilisateurs dans l'évaluation, le “feed-back” et la définition des besoins (guidé par les cas d'utilisation);
4. construction d'une architecture centrale cohérente et stable dès les premières itérations (centré dur l'architecture);
5. contrôle de qualité continuel : tests précoces, fréquents et en situation réelle;
6. il utilise les technologies objet, notamment l'analyse, la conception et la programmation orientées objet;
7. il utilise la notation graphique standard pour la modélisation visuelle (UML);
8. il gère rigoureusement des spécifications (définit et gère des besoins);
9. il applique la pratique des demandes de changement et de la gestion de configuration (construction/feed-back/adaptation itératifs convergent vers le SI souhaité en diminuant l'instabilité des spécifications et conception avec le temps).

Le PU organise les itérations d'un projet en 4 phases majeures :

1. Initialisation ou inception
2. Élaboration
3. Construction
4. Transition

Initialisation ou Inception (étude d'opportunité) qui comprend l'étude du marché, la spécification du produit final et la définition de la portée du projet (vision approximative de la finalité du projet, estimations globales). Cette phase peut faire appel à une maquette pour déterminer la visibilité du projet ou sa faisabilité technique dont l'évaluation permet de prendre la décision de poursuivre ou non le projet.

Pendant la phase d'initialisation il faut :

1. Définir la vision globale du projet;
2. Définir les processus métiers (processus d'affaire) impliqués avec le SI;
3. Délimiter les frontières du projet;
4. Identifier les entités externes qui interagiront avec le SI;
5. Identifier et décrire les principaux cas d'utilisation et scénarios.
6. Identifier les risques.
7. Définir les bornes pour chaque incrément.

L'inception peut se définir en une phrase : Déterminer la portée, la vision et l'opportunité du projet ou du produit. Le principal problème à résoudre pendant la phase d'inception peut se résumer en une phrase : Les parties prenantes sont-elles globalement d'accord sur la vision du projet, et celui-ci mérite-t-il une étude approfondie ? La durée de la phase d'inception ne doit pas dépasser une à quelques semaine (une semaine dans la plupart de cas).

Correspond à la spécification des particularités du produit, à la planification des activités, à la détermination des ressources, à la conception, l'implémentation et à la validation itérative de l'architecture noyau du logiciel (vision plus élaborée du projet, estimations plus réalistes, résolution des risques élevés, identification de la plupart des besoins et du périmètre réel du projet). Cette phase fournit plusieurs prototypes d'architecture dans le but de définir une bonne architecture de base.

Pendant la phase d'élaboration il faut :

1. Définir des exigences;
2. Analyser le domaine;
3. Définir un glossaire du domaine;
4. Créer une ossature de l'architecture;
5. Planifier le projet;
6. Définir des scénarios supportés par chaque incrément;
7. Éliminer les facteurs de risques les plus élevés.

Regroupe la réalisation du produit, à l'adaptation de la vision, de l'architecture et des plans, jusqu'à la livraison du produit (implémentation itérative des composantes, préparation du déploiement). Cette phase progresse au rythme des prototypes de développement, dont l'objectif premier est de mesurer les progrès et de garantir la stabilisation de la conception. La phase de construction se termine par la livraison de version préliminaire (version bêta) qui est placée chez des utilisateurs en vue d'être testée dans l'environnement de déploiement.

Pendant la phase de construction il faut :

1. Définir les cas d'utilisation restants;
2. Décrire les scénarios pour les cas d'utilisation définis;
3. Développer un modèle objet complet;
4. Détailler les diagrammes de séquence;
5. Implémenter les classes;
6. Créer les scénarios de tests basés sur les cas d'utilisation st sur l'architecture.

Rassemble la fabrication à grande échelle, la formation, le déploiement dans la communauté des utilisateurs, le support technique et la maintenance. Cette phase débute par l'installation des versions bêta sur le site et progresse au rythme de livraisons des versions qui viennent corriger les défauts détectés par les utilisateurs. Selon les organisations, la phase de transition s'arrête lorsque la version de production est disponible, ou que la génération suivante est livrée aux utilisateurs.

Pendant la phase de transition il faut :

1. Confier le SI aux utilisateurs;
2. Préparer les plans de formation pour les utilisateurs;
3. Décrire les livrables;
4. Mettre au point et résoudre les besoins mal compris;
5. Définir la portée de la prochaine mise à jour.

Une itération est un ordre des activités avec un plan établi et des critères d'évaluation, ayant pour résultat une version exécutable du produit (interne ou externe).

Il appartient à chaque projet de déterminer le nombre d'itérations de chaque phase.

Le PU est construit autour des concepts de phases du cycle d'évolution du projet et de flux de travail ou disciplines (workflow).

Une discipline est un ensemble d'activités de la modélisation à la définition de l'environnement dans un domaine donné.

Chaque activité est associée à un ensemble d'artefacts ou de produits qui lui sont liés.

L'artefact est le terme générique qui désigne n'importe quel produit du travail de développement de SI : diagrammes UML, code, schémas de BD, modèles, documents texte, etc.

UP gère le processus de développement par deux axes :

• L'axe vertical représente les principaux enchaînements d'activités, qui regroupent les activités selon leur nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en terme de composants, de processus, d'activités, d'enchaînements, d'artefacts et de travailleurs.
• L'axe horizontal représente le temps et montre le déroulement du cycle de vie du processus; cette dimension rend compte de l'aspect dynamique du processus qui s'exprime en terme de cycles, de phases, d'itérations et de jalons.

[]

La charge de travail relative dans les disciplines varie selon les phases. Généralement, en phase d'élaboration, on a une charge de travail relativement élevée pour l'analyse des besoins et la conception, même si elle inclue également un peu d'implémentation. En phase de construction, on favorise l'implémentation et les tests et en phase de transition, le déploiement.

Remarques :

1. En pratique les disciplines d'analyse et de conception sont souvent combinées.
2. Dans le PU, l'implémentation désigne la programmation et la construction du système, non le déploiement.
3. Dans le PU, l'environnement désigne le choix et la personnalisation du processus (installation de l'environnement outils/processus).

Répartition des activités par rapports aux phases du PU. Rappel sur les activités de développement de SI :

1. Analyse besoins (analyse)
2. Conception (architecture)
3. Programmation
4. Validation & vérification
5. Préparation des tests (test)
6. Gestion projet/planification
7. Assurance et contrôle qualité - gestion de versions (gestion des changements et maintenance)

L'importance de chaque activité de développement de SI varie d'une phase du PU à l'autre. L'effort est réparti différemment selon les phases de développement et cette répartition peut varier considérablement selon les caractéristiques du projet. La situation typique représentant un projet de taille moyenne est comme suit.

<gchart 350×120 pie3d #0000ff #ffffff left> Planification = 15 Analyse = 10 Architecture = 15 Réalisation = 30 Maintenance = 5 Tests = 15 Gestion des changements = 10 </gchart>

Chaque phase de développement du PU apporte sa contribution à la réduction des risques :

1. Initialisation (inception dans le RUP) essaie de délimiter les risques du projet, en construisant une maquette pour valider les concepts.
2. Élaboration commence par réduire les risques d'incompréhension entre les utilisateurs et les développeurs, puis valide les choix d'architecture.
3. Construction supprime progressivement les risques de discordance.
4. Transition réduit les risques de prise en main du logiciel.

Le PU est un processus “agile”, c'est-à-dire léger (l'ensemble d'activités peut être restreint, pas de plan global détaillé) et adoptif (avec le CVL itératif dont les spécifications et la conception sont mises à jour jusqu'au début de l'implémentation). Le PU est un processus :

• Itératif et incrémental (cette démarche doit s'appliquer à l'ensemble du CVL, en favorisant le prototypage).
• Guidé par le cas d'utilisation (les cas d'utilisation sont utilisés pour la création et la validation de l'architecture du SI, pour la définition des procédures de tests, pour la planification des itérations, pour la création de la documentation pour les utilisateurs, pour le déploiement du SI et pour la synchronisation du contenu des différents modèles).

• Centré sur l'architecture (le PU prescrit des raffinements successifs d'une architecture exécutable).

Une architecture adaptée est la clé de voûte du succès d'un développement, elle décrit des choix stratégiques déterminant en grande partie les qualités du logiciel (adaptabilité, performance, fiabilité, etc). UML a été fortement inspiré de vue “4+1” proposant des différentes perspectives, indépendantes et complémentaires pour définir un modèle d'architecture.

• Piloté par une analyse des risques (dès le début on essaie de maîtriser la part d'inconnu et d'incertitudes qui caractérisent les SI complexes).

Tableau récapitulatif des objectifs, des mesures et des résultats des phases de PU.

1. Diminution des échecs, amélioration de la productivité et de la qualité (développement itératif et évolutif – incrémental) ;
2. Gestion précoce des risques élevés (risques techniques, spécifications, objectifs, facilité d'utilisation,…) ;
3. Progrès immédiatement visibles ;
4. Feed-back, implication des utilisateurs et adaptation précoces (SI va répondre aux besoins réels des parties prenantes) ;
5. Complexité gérée (plus de « paralysie par l'analyse » et d'épuisement par la longueur ou la complexité des étapes) ;
6. Possibilité d'exploiter méthodiquement les leçons tirées d'une itération.