2 TUP signifie « 2 Track Unified Process »: c’est un processus de développement logiciel qui implémente le Processus Unifié (UP).
2 TUP est un processus qui apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’information de l’entreprise.
SeleccióN De Textos Del Ideario De Jose MartiAdalberto
El documento presenta extractos del ideario de José Martí sobre temas como ética, política, acción, agradecimiento, amargura, América, amistad, ancianidad y crítica. Los extractos destacan ideas como que poseer algo conlleva el deber de usarlo bien, la importancia de prever peligros en política, que la luz de las buenas acciones ilumina como las estrellas, la obligación de superar la amargura y no amargar a otros, y que la crítica debe señalar defectos con noble intención y no de forma de
2 TUP signifie « 2 Track Unified Process »: c’est un processus de développement logiciel qui implémente le Processus Unifié (UP).
2 TUP est un processus qui apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’information de l’entreprise.
SeleccióN De Textos Del Ideario De Jose MartiAdalberto
El documento presenta extractos del ideario de José Martí sobre temas como ética, política, acción, agradecimiento, amargura, América, amistad, ancianidad y crítica. Los extractos destacan ideas como que poseer algo conlleva el deber de usarlo bien, la importancia de prever peligros en política, que la luz de las buenas acciones ilumina como las estrellas, la obligación de superar la amargura y no amargar a otros, y que la crítica debe señalar defectos con noble intención y no de forma de
Inria - Plaquette du centre de recherche Lille - Nord EuropeInria
Le centre de recherche Inria Lille – Nord Europe donne accès aux meilleures recherches européennes et internationales au bénéfice de l’innovation et des entreprises notamment en région. Fort de cette dynamique, le centre affiche une politique internationale de recrutement et d’accueil attractive.
El documento presenta diferentes teorías y enfoques sobre el aprendizaje. Expone las teorías conductista, cognitiva y sociocultural, así como las contribuciones de Piaget, Bruner, Ausubel y Vygotsky. También describe métodos activos como el aprendizaje cooperativo y basado en problemas. El aprendizaje se define como un cambio perdurable de conducta a través de la experiencia, y se analizan conceptos como asimilación, acomodación y andamiaje en el desarrollo cognitivo.
La Ley de la Carrera Docente tiene como objetivo regular las relaciones entre el Estado, la comunidad educativa y los educadores. Establece el Registro Escalafonario del Ministerio de Educación para llevar un control sistemático de los educadores. También regula aspectos como la formación de educadores, los requisitos para ejercer la docencia, el reconocimiento de antigüedad y la administración del escalafón magisterial. El propósito final es garantizar una educación de calidad mediante la profesionalización, seguridad y bienestar de los
El documento presenta un registro de sitios web relacionados con la formulación de proyectos sociales. El objetivo es elaborar un portafolio electrónico con direcciones que sirvan como guía para la planificación, ejecución y evaluación de proyectos. Se concluye que existen diversos formatos y sitios que brindan información sobre cómo elaborar proyectos de manera exitosa.
Résultats enquête publication liens d'intérêts au 1er octobre 2013Market iT
Enquête sur les conditions dans lesquelles les entreprises ont réalisé la première publication de leurs liens d’intérêts avec les Professionnels de Santé.
Enquête menée par le Think Tank Loi Bertrand en collaboration avec :
l’AFAR, Association Française des Affaires Réglementaires,
la FNIM, Fédération Nationale de l’Information Médicale.
Mondragon Team Academy ofrece programas de aprendizaje autogestionado para emprendedores de equipo. Sus programas incluyen títulos universitarios y posgrados en liderazgo emprendedor e innovación, así como programas profesionales básicos. El aprendizaje se basa en el método de "aprender haciendo" a través de proyectos reales y empresas cooperativas. El objetivo es que los emprendedores dirijan su propio aprendizaje mediante contratos de aprendizaje y evaluación continua para alcanzar sus met
El documento describe la Educación Básica Regular en Perú. Consiste en tres niveles - Educación Inicial, Primaria y Secundaria - con objetivos de desarrollar aprendizajes, capacidades y formar integralmente al estudiante. Explica la organización, fundamentos y componentes del Diseño Curricular Nacional, incluyendo logros educativos, áreas curriculares y tutoría.
La feria pedagógica departamental de Sonsonate de 2010 se llevará a cabo el 17 de febrero en el Instituto Nacional Thomas Jefferson. Participarán directores de 15 centros escolares expositores así como representantes de Save the Children. Los centros escolares presentarán experiencias en educación para la transición, desarrollo del lenguaje e inclusión educativa. La feria se realizará de 7:30 a.m. a 3:00 p.m. en el auditórium del Centro Escolar República de Haití.
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...Horgix
This is the slide deck of a talk by Alexis "Horgix" Chotard and Laurentiu Capatina presented at the MongoDB Paris User Group in June 2024 about the feedback on how PayFit move away from a monolithic hell of a self-hosted MongoDB cluster to managed alternatives. Pitch below.
March 15, 2023, 6:59 AM: a MongoDB cluster collapses. Tough luck, this cluster contains 95% of user data and is absolutely vital for even minimal operation of our application. To worsen matters, this cluster is 7 years behind on versions, is not scalable, and barely observable. Furthermore, even the data model would quickly raise eyebrows: applications communicating with each other by reading/writing in the same MongoDB documents, documents reaching the maximum limit of 16MiB with hundreds of levels of nesting, and so forth. The incident will last several days and result in the loss of many users. We've seen better scenarios.
Let's explore how PayFit found itself in this hellish situation and, more importantly, how we managed to overcome it!
On the agenda: technical stabilization, untangling data models, breaking apart a Single Point of Failure (SPOF) into several elements with a more restricted blast radius, transitioning to managed services, improving internal accesses, regaining control over risky operations, and ultimately, approaching a technical migration when it impacts all development teams.
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
1. Processus de Développement Logiciel
Cours M14
Pierre Gérard
Université de Paris 13 IUT Villetaneuse Formation Continue
Licence Pro SIL - 2007/2008
Table des matières
1 Des besoins au code avec UML 1
2 Rational Unied Process 9
3 eXtreme programming 19
2.
3. 1 DES BESOINS AU CODE AVEC UML
1 Des besoins au code avec UML
Nécessité d'une méthode
Processus de développement
Ensemble d'étapes partiellement ordonnées, qui concourent à l'obtention d'un système logiciel
ou à l'évolution d'un système existant.
Objectif : produire des logiciels
De qualité (qui répondent aux besoins de leurs utilisateurs)
Dans des temps et des coûts prévisibles
A chaque étape, on produit
Des modèles
De la documentation
Du code
Méthode = Démarche + Langage
La méthode MERISE fournit
Un langage de modélisation graphique (MCD, MPD, MOT, MCT...)
ET Une démarche à adopter pour développent un logiciel
UML n'est qu'un langage
Spécie comment décrire des cas d'utilisation, des classes, des interactions...
Ne préjuge pas de la démarche employée
Méthodes s'appuyant sur UML
RUP (Rational Unied Process) - par les auteurs d'UML
XP (eXtreme Programming) - pouvant s'appuyer sur UML
Méthode minimale
Objectif
Résoudre 80% des problèmes avec 20% d'UML
Proposition d'une méthode archi-minimale
Vraiment très très nettement moins complexe que RUP
Adaptée pour des projets modestes
Minimum vital pour qui prétend utiliser un peu UML
Inspirée de
UML 2 - Modéliser une application web
Pascal Roques
Editions Eyrolles (2006)
Processus de Développement Logiciel 1 / 25
4. 1 DES BESOINS AU CODE AVEC UML
Cas d'utilisation
Comment aboutir au diagramme de cas d'utilisation ?
1. Identier les limites du système
2. Identier les acteurs
3. Identier les cas d'utilisation
4. Structurer les cas d'utilisation en packages
5. Ajouter les relations entre cas d'utilisation
6. Classer les cas d'utilisation
Exemple de classement
Cas d'utilisation Priorité Risque
Rechercher des ouvrages Haute Moyen
Gérer son panier Haute Bas
Eectuer une commande Moyenne Haut
Consulter ses commandes en cours Basse Moyen
Consulter l'aide en ligne Basse Bas
Maintenir le catalogue Haute Haut
Maintenir les informations éditoriales Moyenne Bas
Maintenir le site Moyenne Bas
Un tel classement permet de déterminer les cas d'utilisation centraux en fonction
de leur priorité fonctionnelle
du risque qu'il font courrir au projet dans son ensemble
Les fonctionnalités des cas les plus centraux seront développées en premier lieu
Modèle du domaine
Le modèle du domaine est constitué d'un ensemble de classes dans lesquelles aucune opération
n'est dénie
Le modèle du domaine décrit les concepts invariants du domaine d'application
Exemple : Pour un logiciel de gestions de factures, on aura des classes comme Produit,
Client, Facture...
Peu importe que le logiciel soit en ligne ou non
Peu importe qu'on utilise php ou ajax
2 / 25 Processus de Développement Logiciel
5. 1 DES BESOINS AU CODE AVEC UML
Etapes de la démarche :
1. Identier les concepts du domaine
2. Ajouter les associations et les attributs
3. Généraliser les concepts
4. Structurer en packages : structuration selon les principes de cohérence et d'indépen-
dance.
Les concepts du domaine peuvent être identiés directement à partir de la connaissance
du domaine ou par interview des experts métier.
Exemple de modèle du domaine
Structuration en packages
Dénition synthétique des packages
Processus de Développement Logiciel 3 / 25
6. 1 DES BESOINS AU CODE AVEC UML
Diagramme de séquence système
Un diagramme de séquence système est une formalisation des descriptions textuelles des cas
d'utilisation
Un diagramme diérent est produit pour chaque cas d'utilisation.
Construire un DSS implique la
Construction des diagrammes de séquence système
Mise à jour des cas d'utilisation (on peut réviser le diagramme de cas à la lumière des
réexions que nous inspirent la production des DSS)
Spécication des opérations système
Le système est considéré comme un tout
On s'intéresse à ses interactions avec les acteurs
Les diagrammes de séquence système sont parfois très simples mais ils seront enrichis par
la suite
Exemple de diagramme de séquence système
Opérations système
Les opérations système sont des opérations qui devront être réalisées par l'une ou l'autre
des classes du système
4 / 25 Processus de Développement Logiciel
7. 1 DES BESOINS AU CODE AVEC UML
Elles correspondent à tous les messages qui viennent des acteurs vers le système dans les
diérents DSS
Classes d'analyse
Réalisation des cas d'utilisation par les classes d'analyse
Typologie des classes d'analyse
Les classes dialogue sont celles qui permettent les interactions entre les utilisateurs et
l'application.
Les classes contrôle contiennent la dynamique de l'application
Elles font le lien entre les classes dialogue et les classes métier.
Elles permettent de contrôler la cinématique de l'application, l'ordre dans lequel les
choses doivent se dérouler.
Les classes métier ou entités représentent les objets métier. Elles proviennent directement
du modèle du domaine (mais peuvent être complétées en fonction des cas d'utilisation).
Les classes d'analyse sont les classes métier auxquelles on adjoint toutes les classes sui permettront
au système de fonctionner : dialogues et contrôles
Diagramme de classes participantes
Le diagramme des classes participantes est un diagramme de classes décrivant les classes d'analyse
et dans lequel on ajoute les acteurs
A ce point du développement, seules les classes dialogue ont des opérations (actions de
l'utilisateur sur l'IHM)
Ces opérations correspondent aux opérations système, c'est à dire aux messages entrants
que seules les classes de dialogues sont habilitées à intercepter.
Associations :
Les dialogues ne peuvent être reliés qu'aux contrôles ou à d'autres dialogues (en général,
associations unidirectionnelles)
Les classes métier ne peuvent être reliées qu'aux contrôles ou à d'autres classes métier.
Les contrôles ont accès à tous les types de classes.
Exemples de classes participantes
Processus de Développement Logiciel 5 / 25
8. 1 DES BESOINS AU CODE AVEC UML
Diagramme d'activités de navigation
Modélisation de l'Interface Homme-Machine (IHM) avec des diagrammes d'activité
Les activités peuvent représenter des écrans, des fenêtres de l'application, des pages
php...
Exploitation des maquettes de manière à représenter l'ensemble des chemins possibles entre
les principaux écrans proposés à l'utilisateur.
Exemple de diagramme d'activités de navigation
Diagrammes d'interaction
Dans les diagrammes de séquence système, le système était vu comme une boîte noire
Mais on sait maintenant de quels types d'objets est composé le système (diag. de classes
participantes)
Le système n'est plus une boîte noire.
Chaque diagramme de séquence système donne lieu à un diagramme d'interaction
Les diagrammes d'interaction montrent les interactions du système avec l'extérieur et les
interactions internes qu'elles provoquent
Les DSS sont repris mais l'objet système est éclaté pour donner le détail des classes
d'analyse
Les lignes de vie correspondent aux classes participantes
Des séquences système aux interactions internes
6 / 25 Processus de Développement Logiciel
9. 1 DES BESOINS AU CODE AVEC UML
Diagramme des classes de conception
Enrichissement du diagramme de classes pour
Prendre en compte l'architecture logicielle hôte
Modéliser les opération privées des diérentes classes
Finaliser le modèle des classes avant l'implémentation
On peut utiliser des diagrammes de séquence pour détailler :
Les interactions entre classes
Cartains algorithmes
Processus de Développement Logiciel 7 / 25
10.
11. 2 RATIONAL UNIFIED PROCESS
2 Rational Unied Process
Modèles de cycles de vie linéaire
Les phases du développement se suivent dans l'ordre et sans retour en arrière
Problèmes des cycles linéaires
Risques élevés et non contrôlés
Identication tardive des problèmes
Preuve tardive de bon fonctionnement
Eet tunnel
Améliorations : construction itérative du système
Chaque itération produit un nouvel incrément
Chaque nouvel incrément a pour objectif la maîtrise d'une partie des risques et apporte
une preuve tangible de faisabilité ou d'adéquation
Enrichissement d'une série de prototypes
Les versions livrées correspondent à des étapes de la chaîne des prototypes
Production itérative d'incréments
Itérations 0 1 2 3 4 5 6 7
Processus de Développement Logiciel 9 / 25
13. 2 RATIONAL UNIFIED PROCESS
A chaque itération, on refait
1. Spécication
2. Conception
3. Implémentation
4. Tests
Elimination des risques à chaque itération
On peut voir le développement d'un logiciel comme un processus graduel d'élimination de risques
Processus de Développement Logiciel 11 / 25
14. 2 RATIONAL UNIFIED PROCESS
C'est pendant Planication et éxécution qu'on répète Spécication → Conception →
Implémentation → Tests
Rational Unied Process
RUP est une démarche de développement qui est souvent utilisé conjointement au langage UML
Rational Unied Process est
Piloté par les cas d'utilisation
Centré sur l'architecture
Itératif et incrémental
RUP est itératif et incrémental
Chaque itération prend en compte un certain nombre de cas d'utilisation
Les risques majeurs sont traités en priorité
Chaque itération donne lieu à un incrément et produit une nouvelle version exécutable
RUP est piloté par les cas d'utilisation
La principale qualité d'un logiciel est son utilité
Adéquation du service rendu par le logiciel avec les besoins des utilisateurs
Le développement d'un logiciel doit être centré sur l'utilisateur
Les cas d'utilisation permettent d'exprimer ces besoins
Détection et description des besoins fonctionnels
Organisation des besoins fonctionnels
RUP est centré sur l'architecture
Modélisation de diérentes pespectives indépendantes et complémentaires
Architecture en couches et vues de Krutchen
Vues du système
Vue cas d'utilisation
Description du système comme un ensemble de transactions du point de vue de l'util-
isateur
Vue logique
Créée lors de la phase d'élaboration et ranée lors de la phase de construction
Utilisation de diagrammes de classes, de séquences...
Vue composants
Description de l'architecture logicielle
Vue déploiement
Description de l'architecture matérielle du système
Vue implémentation
Description des algorithmes, code source
12 / 25 Processus de Développement Logiciel
15. 2 RATIONAL UNIFIED PROCESS
Organisation en phases du développement
Initialisation
Dénition du problème
Elaboration
Planication des activités, aectation des ressources, analyse
Construction
Développement du logiciel par incréments successifs
Transition
Recettage et déploiement
Les phases du développement sont les grandes étapes du développement du logiciel
Le projet commence en phase d'initialisation et termine en phase de transition
Phase d'initialisation : Objectifs
Dénition du cadre du projet, son concept, et inventaire du contenu
Elaboration des cas d'utilisation critiques ayant le plus d'inuence sur l'architecture et la
conception
Réalisation d'un ou de plusieurs prototypes démontrant les fonctionnalités décrites par les
cas d'utilisation principaux
Estimation détaillée de la charge de travail, du coût et du planning général ainsi que de la
phase suivante d'élaboration Estimation des risques
Phase d'initialisation : Activités
Formulation du cadre du projet, des besoins, des contraintes et des critères d'acceptation
Planication et préparation de la justication économique du projet et évaluation des
alternatives en termes de gestion des risques, ressources, planication
Synthèse des architectures candidates, évaluation des coûts
Phase d'initialisation : Livrables
Un document de vision présentant les besoins de base, les contraintes et fonctionnalités
principales
Une première version du modèle de cas d'utilisation
Un glossaire de projet
Un document de justication économique incluant le contexte général de réalisation, les
facteurs de succès et la prévision nancière
Une évaluation des risques
Un plan de projet présentant phases et itérations
Un ou plusieurs prototypes
Phase d'initialisation : Critères d'évaluation
Un consensus sur
la planication,
les coûts
la dénition de l'ensemble des projets des parties concernées
La compréhension commune des besoins
Phase d'élaboration : objectifs
Dénir, valider et arrêter l'architecture
Démontrer l'ecacité de cette architecture à répondre à notre besoin
Planier la phase de construction
Processus de Développement Logiciel 13 / 25
16. 2 RATIONAL UNIFIED PROCESS
Phase d'élaboration : activités
Elaboration de la vision générale du système, les cas d'utilisation principaux sont compris
et validés
Le processus de projet, l'infrastructure, les outils et l'environnement de développement
sont établis et mis en place
Elaboration de l'architecture et sélection des composants
Phase d'élaboration : livrables
Le modèle de cas d'utilisation est produit au moins à 80 %
La liste des exigences et contraintes non fonctionnelles identiées
Une description de l'architecture
Un exécutable permettant de valider l'architecture du logiciel à travers certaines fonction-
nalités complexes
La liste des risques revue et la mise à jour de la justication économique du projet
Le plan de réalisation, y compris un plan de développement présentant les phases, les
itérations et les critères d'évaluation
Phase d'élaboration : Critères d'évaluation
La stabilité de la vision du produit nal
La stabilité de l'architecture
La prise en charge des risques principaux est adressée par le(s) prototype(s)
La dénition et le détail du plan de projet pour la phase de construction
Un consensus, par toutes les parties prenantes, sur la réactualisation de la planication,
des coûts et de la dénition de projet
Phase de construction : objectifs
La minimisation des coûts de développement par
l'optimisation des ressources
la minimisation des travaux non nécessaires
Le maintien de la qualité
Réalisation des versions exécutables
Phase de construction : Activités
La gestion et le contrôle des ressources et l'optimisation du processus de projet
Evaluation des versions produites en regard des critères d'acceptation dénis
Phase de construction : Livrables
Les versions exécutables du logiciel correspondant à l'enrichissement itération par itération
des fonctionnalités
Les manuels d'utilisation réalisés en parallèle à la livraison incrémentale des exécutables
Une description des versions produites
Phase de construction : Critères d'évaluation
La stabilité et la qualité des exécutables
La préparation des parties prenantes
La situation nancière du projet en regard du budget initial
Phase de transition : Objectifs
Le déploiement du logiciel dans l'environnement d'exploitation des utilisateurs
La prise en charge des problèmes liés à la transition
Atteindre un niveau de stabilité tel que l'utilisateur est indépendant
14 / 25 Processus de Développement Logiciel
17. 2 RATIONAL UNIFIED PROCESS
Atteindre un niveau de stabilité et qualité tel que les parties prenantes considèrent le projet
comme terminé
Phase de transition : Activités
Activités de packaging du logiciel pour le mettre à disposition des utilisateurs et de
l'équipe d'exploitation
Correction des erreurs résiduelles et amélioration de la performance et du champ d'utilisa-
tion
Evaluation du produit nal en regard des critères d'acceptation dénis
Phase de transition : Livrables
La version nale du logiciel
Les manuels d'utilisation
Phase de transition : Critères d'évaluation
La satisfaction des utilisateurs
La situation nancière du projet en regard du budget initial
Organisation en activités de développement
Chaque phase comprend plusieurs itérations
Pour chacune des itérations, on se livre à plusieurs activités
Modélisation métier
Expression des besoins
Analyse
Conception
Implémentation
Test
Dépoloiement
Les activités sont des étapes dans le développement d'un logiciel, mais à un niveau de
granularité beaucoup plus n que les phases
Chaque activité est répétée autant de fois qu'il y a d'itérations
Modélisation métier
Objectif : Mieux comprendre la structure et la dynamique de l'organisation.
Proposer la meilleure solution dans le contexte de l'organisation cliente.
Réalisation d'un glossaire des termes métiers.
Cartographie des processus métier de l'organisation cliente.
Activité coûteuse mais qui permet d'accélérer la compréhension d'un problème
Processus de Développement Logiciel 15 / 25
18. 2 RATIONAL UNIFIED PROCESS
Expression des besoins
Objectif : Cibler les besoins des utilisateurs et du clients grâce à une série d'interviews.
L'ensemble des parties prenantes du projet, maîtrise d'oeuvre et maîtrise d'ouvrage, est
acteur de cette activité.
L'activité de recueil et d'expression des besoins débouche sur ce que doit faire le système
(question QUOI ? )
Utilisation des cas d'utilisation pour
Schématiser les besoins
Structurer les documents de spécications fonctionnelles.
Les cas d'utilisation sont décomposés en scénarios d'usage du système, dans lesquels l'util-
isateur raconte ce qu'il fait grâce au système et ses interactions avec le système.
Un maquettage est réalisable pour mieux immerger l'utilisateur dans le futur système.
Une fois posées les limites fonctionnelles, le projet est planié et une prévision des coûts
est réalisée.
Analyse
Objectif : Transformer les besoins utilisateurs en modèles UML
Analyse objet servant de base à une réexion sur les mécanismes internes du système
Principaux livrables
Modèles d'analyse, neutre vis à vis d'une technologie.
Livre une spécication plus précise des besoins
Peut envisagé comme une première ébauche du modèle de conception
Conception
Objectif : Modéliser comment le système va fonctionner
Exigences non fonctionnelles
Choix technologiques.
Le système est analysé et on produit
Une proposition d'architecture.
Un découpage en composants.
Impémentation
Objectif : Implémenter le système par composants.
Le système est développé par morceaux dépendant les uns des autres.
Optimisation de l'utilisation des ressources selon leurs expertises.
Les découpages fonctionnel et en couches sont indispensable pour cette activité.
Il est tout à fait envisageable de retoucher les modèles d'analyse et de conception à ce
stade.
Test
Objectif : Vérier des résultats de l'implémentation en testant la construction.
Tests unitaires : tests composants par composants
Tests d'intégration : tests de l'interaction de composants préalablement testés individu-
ellement
Méthode :
Planication pour chaque itération
Implémentation des tests en créant des cas de tests
Exécuter les tests
Prendre en compte le résultat de chacun.
16 / 25 Processus de Développement Logiciel
19. 2 RATIONAL UNIFIED PROCESS
Déploiement
Objectif : Déployer les développements une fois réalisés.
Peut être réalisé très tôt dans le processus dans une sousactivité de prototypage dont
l'objectif est de valider
l'architecture physique
les choix technologiques.
Importance des activités dans chaque phase
Principaux diagrammes UML par activité
Expression des besoins et modélisation métier
Modèles métier, domaine, cas d'utilisation
Diagramme de séquences
Diagramme d'activité
Analyse
Modèles métier, cas d'utilisation
Diagramme des classes, de séquences et de déploiement
Conception
Diagramme des classes, de séquences
Diagramme état/transition
Diagramme d'activité
Diagramme de déploiement et de composant
2TUP, une variante du Unied Process
2TUP, avec un processus de développement en Y , développé par Valtech
UML 2.0, en action : De l'analyse des besoins à la conception J2EE
Pascal Roques, Franck Vallée
Editions Eyrolles (2004)
Processus de Développement Logiciel 17 / 25
20.
21. 3 EXTREME PROGRAMMING
3 eXtreme programming
Méthodes agiles
Quelles activités pouvons nous abandonner tout en produisant des logiciels de qualité ?
Comment mieux travailler avec le client pour nous focaliser sur ses besoins les plus prioritaires
et être aussi réactifs que possible?
Filiation avec le RAD
Exemples de méthodes agiles
XP (eXtreme Programming), DSDM (Dynamic Software Development Method), ASD
(Adaptative Software Development), CCM (Crystal Clear Methodologies), SCRUM,
FDD (Feature Driven Development)
Priorités des méthodes agiles
Priorité aux personnes et aux interactions sur les procédures de les outils
Priorité aux applications fonctionnelles sur une documentation pléthorique
Priorité à la collaboration avec le client sur la négociation de contrat
Priorité à l'acceptation du changement sur la planication
eXtreme Programming
eXtreme Programming, une méthode basée sur des pratiques qui sont autant de boutons poussés
au maximum
Méthode qui peut sembler naturelle mais concrètement dicile à appliquer et à maîtriser
Réclame beaucoup de discipline et de communication (contrairement à la première im-
pression qui peut faire penser à une ébullition de cerveaux individuels).
Aller vite mais sans perdre de vue la rigueur du codage et les fonctions nales de l'ap-
plication.
Force de XP : sa simplicité et le fait qu'on va droit à l'essentiel, selon un rythme qui doit
rester constant.
Valeurs d'XP
Communication
XP favorise la communication directe, plutôt que le cloisonnement des activités et les
échanges de documents formels.
Les développeurs travaillent directement avec la maîtrise d'ouvrage
Feedback
Les pratiques XP sont conçues pour donner un maximum de feedback sur le déroulement
du projet an de corriger la trajectoire au plus tôt.
Simplicité :
Du processus
Du code
Courage :
d'honorer les autres valeurs
de maintenir une communication franche et ouverte
d'accepter et de traiter de front les mauvaises nouvelles.
Processus de Développement Logiciel 19 / 25
22. 3 EXTREME PROGRAMMING
Pratiques d'XP
XP est fondé sur des valeurs, mais surtout sur 13 pratiques réparties en 3 catégories
Gestion de projets
Programmation
Collaboration
Pratiques de gestion de projets
Livraisons fréquentes
L'équipe vise la mise en production rapide d'une version minimale du logiciel, puis elle
fournit ensuite régulièrement de nouvelles livraisons en tenant compte des retours du
client.
Planication itérative
Un plan de développement est préparé au début du projet, puis il est revu et remanié
tout au long du développement pour tenir compte de l'expérience acquise par le client
et l'équipe de développement.
Client sur site
Le client est intégré à l'équipe de développement pour répondre aux questions des
développeurs et dénir les tests fonctionnels.
Rythme durable
L'équipe adopte un rythme de travail qui lui permet de fournir un travail de qualité tout
au long du projet.
Jamais plus de 40h de travail par semaine (un développeur fatigué développe mal)
Pratiques de programmation
Conception simple
On ne développe rien qui ne soit utile tout de suite.
Remaniement
Le code est en permanence réorganisé pour rester aussi clair et simple que possible.
Tests unitaires
Les développeurs mettent en place une batterie de tests de nonrégression qui leur per-
mettent de faire des modications sans crainte.
Tests de recette
Les testeurs mettent en place des tests automatiques qui vérient que le logiciel répond
aux exigences du client.
Ces tests permettent des recettes automatiques du logiciel.
Pratiques de collaboration
Responsabilité collective du code
Chaque développeur est susceptible de travailler sur n'importe quelle partie de l'appli-
cation.
Programmation en binômes
Les développeurs travaillent toujours en binômes, ces binômes étant renouvelés fréquem-
ment.
Règles de codage
Les développeurs se plient à des règles de codage strictes dénies par l'équipe elle-même.
Métaphore
Les développeurs s'appuient sur une description commune du design.
Intégration continue
L'intégration des nouveaux développements est faite chaque jour.
Cycle de vie XP
20 / 25 Processus de Développement Logiciel
23. 3 EXTREME PROGRAMMING
Exploration
Les développeurs se penchent sur des questions techniques
Explorer les diérentes possibilités d'architecture pour le système
Etudier par exemple les limites au niveau des performances présentées par chacune des
solutions possibles
Le client s'habitue à exprimer ses besoins sous forme de user strories (proches de dia-
grammes de cas illustrés par des diagrammes de séquences)
Les développeurs estiment les temps de développement
Planning
Planning de la première release :
Uniquement les fonctionnalités essentielles
Première release à enrichir par la suite
Durée du planning : 1 ou 2 jours
Première version (release) au bout de 2 à 6 mois
Itérations jusqu'à la première release
Développement de la première version de l'application
Itérations de une à quatre semaines
Chaque itération produit un sous ensemble des fonctionnalités principales
Le produit de chaque itération subit des tests fonctionnels
Itérations courtes pour identier très tôt des déviation par rapport au planning
Brèves réunions quotidiennes réunissant toute l'équipe, pour mettre chacun au courant de
l'avancement du projet
Mise en production
La mise en production produit un logiciel
Orant toutes les fonctionnalités indispensables
Parfaitement fonctionnel
Mis à disposition des utilisateurs
Itérations très courtes
Tests constants en parallèle du développement
Les développeurs procèdent à des réglages anés pour améliorer les performances du logi-
ciel
Processus de Développement Logiciel 21 / 25
24. 3 EXTREME PROGRAMMING
Maintenance
Continuer à faire fonctionner le système
Adjonction de nouvelles fonctionnalités secondaires
Pour les fonctionnalités secondaires, on recommence par une rapide exploration
L'ajout de fonctionnalités secondaires donne lieu à de nouvelles releases
Mort
Quand le client ne parvient plus à spécier de nouveaux besoins, le projet est dit mort
Soit que tous les besoins possibles sont remplis
Soit que le système ne supporte plus de nouvelles modications en restsant rentable
Equipe XP
Pour un travil en équipe, on distingue 6 rôles principaux au sein d'une équipe XP
Développeur
Client
Testeur
Tracker
Manager
Coach
Développeur
Conception et programmation, même combat !
Participe aux séances de planication, évalue les tâches et leur diculté
Dénition des test unitaires
Implémentation des fonctionnalités et des tests unitaires
Client
Écrit, explique et maîtrise les scénarios
Spécie les tests fonctionnels de recette
Dénit les priorités
Testeur
Écriture des tests de recette automatiques pour valider les scénarios clients
Peut inuer sur les choix du clients en fonction de la testatibilité des scénarios
Tracker
Suivre le planning pour chaque itération.
Comprendre les estimations produites par les développeurs concernant leur charges
Interagir avec les développeurs pour le respect du planning de l'itération courante
Détection des éventuels retards et rectications si besoin
Manager
Supérieur hiérarchique des développeurs
Responsable du projet
Vérication de la satisfaction du client
Contrôle le planning
Gestion des ressources
22 / 25 Processus de Développement Logiciel
25. 3 EXTREME PROGRAMMING
Coach
Garant du processus XP
Organise et anime les séances de planications
Favorise la créativité du groupe, n'impose pas ses solutions techniques
Coup de gueules. . .
Spécication avec XP
Pas de documents d'analyse ou de spécications détaillées
Les tests de recette remplacent les spécications
Emergence de l'architecture au fur et à mesure du développement
XP vs RUP
Inconvénients de XP
Focalisation sur l'aspect individuel du développement, au détriment d'une vue globale
et des pratiques de management ou de formalisation
Manquer de contrôle et de structuration, risques de dérive
Inconvénients de RUP
Fait tout, mais lourd, usine à gaz
Parfois dicile à mettre en oeuvre de façon spécique.
XP pour les petits projets en équipe de 12 max
RUP pour les gros projets qui génèrent beaucoup de documentation
Processus de Développement Logiciel 23 / 25