Modification de Modèles de processus de développement des SI

{{Infobox Lecture
 | image = 
 | cours = [[Gestion de projet]]
 | faculté = [[Faculté d'économie et de management]]
 | département = [[Services généraux GSEM]]
 | domaine = [[Système d'information]]
 | professeurs = [[Jolita Ralyte]]<ref>[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]</ref>
 | années = 
 | code = S204033 CR <ref>[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&p_plan_is=0&p_langue=1&p_frame=N&p_mode=PGC&p_annee=2015&p_suffixe=&p_grtri= Présentation du cours sur le site du catalogue de cours wadme]</ref>
 | enregistrement = 
 | précédent = 
 | suivant = [[Gestion du risque des projets SI]]
}}

=Processus de Développement des SI=
Ensemble structuré d'activités à réaliser pour atteindre l'objectif d'un projet SI, dont les activités varient en fonction de l'organisation, du projet, et du type de système à développer. Ce processus doit être explicitement décrit pour être adéquatement géré.

Le '''cycle de vie d'un SI''' décrit succintement les phases par lesquelles passe un système d'information depuis le '''besoin initial''' jusqu'au '''retrait du système''', la documentation et les décisions qui jalonnent le cycle.

=Activités de développement des SI=

*'''Spécification''' des exigences et des contraintes du système, établissement du cahier des charges
*'''Conception''' de la solution, production d'un modèle du système à développer
*'''Implémentation''' du système
*'''Test''' du système, vérification de l'adéquation entre les propriétés implémentées du système et la spécification des besoins
*'''Installation''' du système chez le client et vérification de son fonctionnement
*'''Maintenance''' du système, réparation des fautes

=Modèles standards de développement des SI=

Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les activités/étapes de développement des SI vus dans le point précédent.


==Code-and-fix==

Modèle dirigé par la programmation.

'''Compréhension du problème''' -> '''Programmation''' -> '''Test contre spécification''' -> '''Fin''' si satisfait, sinon '''Mise au point du code''' et retour au '''Test contre spécification'''

==Transformation automatique==

Développement basé sur la possibilité de transformer automatiquement des spécifications validées en programmes.

Ce modèle nécessite un '''outil logiciel''' qui fait de telles transformations.

'''Spécification''' -> '''Validation''' -> '''Transformation''' si validé, sinon retour à '''Spécification'''.

==Cascade / Waterfall==
[[Fichier:Processus cascade waterfall.png|cadre|centré|Processus de développement en cascade/waterfall]]

Processus de nature plutôt linéaire, centré '''activités''' avec un ordonnancement prédéfini des activités, dans lequel il est toujours possible de revenir en arrière. Ce modèle est hérité de l'industrie lourde (construction de bâtiments, usines, etc.). Les phases nécessitent de plus en plus de ressources. Ce modèle est donc plus adapté aux grands projets de développement qui n'offrent que peu de possibilités d'interactions avec tous les membres de l'équipe qui dépassent la centaine.

===Initiation - Étude de faisabilité===

*Analyser le problème
*Définir les objectifs
*Définir les frontières du système
*Identifier les contraintes imposées (politiques, matériel, temps, technologies, etc.)
*'''Évaluer la faisabilité technique, économique, opérationnelle.'''

yee zbouuub

===Spécification des exigences===

*Définir le périmètre du SI
*Analyser le domaine d'application
*Identifier les exigences :
**fonctionnelles : les activités de l'organisation qui devraient être couvertes par le SI
**non fonctionnelles : les performances techniques, l'environnement d'utilisateur, système d'exploitation, matériel, etc.
*Conceptualiser les besoins (cas d'utilisation, scénarios, objectifs, etc.)
*Déterminer la priorité des besoins
*Valider les exigences avec les utilisateurs
*Élaborer un glossaire de termes

===Analyse===
'''Exploration des solutions possibles : '''
*Analyser les exigences
*Proposer une ou plusieurs solutions conceptuelles 
**Vue structurelle du système (modèle objet)
**Vue dynamique du système (cycle de vie des objets, diagrammes d'activités, etc.)
*Proposer une architecture d'implémentation
*Valider toutes les propositions avec les utilisateurs

===Conception===
'''Spécification détaillée de la solution choisie :'''
*Définir le modèle physique de la base de données
*Définir les contraintes d'intégrité
*Choisir le SGBD
*Modéliser les interfaces utilisateur
*Définir les standards de sécurité du système
*Définir l'architecture du système

===Construction===
'''Développement du code : '''
*Créer les programmes
*Créer et remplir les bases de données
*Intégrer les sous-systèmes
*Écrire la documentation

===Tests===
*Tester les programmes
*Tester le système global

===Mise en place===
*S'assurer que tout le matériel et les réseaux nécessaires pour le nouveau SI sont mis en place
*Installer le système
*Former l'utilisateur

==Modèle en V==
[[Fichier:Processus modele V.png|cadre|centré|Méthode de développement en V]]

Décomposition du système en composants qui peuvent être développés de manière indépendante. Ce modèle permet d'avoir une meilleure réactivité que le modèle en cascade : il permet de limiter les retours en arrière en cas d'anomalie.

==Modèle en W==
[[Fichier:Processus modele W.png|cadre|centré|Modèle de développement en W]]

Ce modèle est une extension du modèle en V, qui améliore l'étape d'analyse des exigences.

===Modèle en W : accent sur les tests===
[[Fichier:Processus modele W-tests.png|cadre|centré|Modèle de développement en W avec accent sur les tests]]

Ce modèle est toujours une extension du modèle en V, mais avec une focalisation sur les '''tests''' à toutes les phases de développement.

==Développement évolutif==

Développement de plusieurs versions d'un logiciel en l'améliorant à chaque fois.

'''Détermination des besoins''' -> '''Programmation''' -> '''Expérimentation''' -> '''Version N''' -> '''Détermination des besoins''' -> ...

==Spirale==
[[Fichier:Processus spirale.png|cadre|centré|Modèle de développement en spirale]]

Ce modèle reprend les différentes étapes du modèle en V en mettant un accent sur la gestion du risque, qui se retrouve à chaque début d'itération de la spirale.

==RAD - Rapid Application Development==

[[Fichier:Processus RAD.png|vignette|droite|Modèle de développement RAD]]

Le RAD est un modèle '''linéaire''' en 5 phases et '''itératif''' pour la phase de construction. Chaque phase est composée d'une ou plusieurs étapes, et chaque étape est organisée en 3 temps :
#Travaux préparatoires
#Session participative
#Travaux de conclusion

Le logiciel est construit en plusieurs modules livrés successivement, et il privilégie aussi le travail d'équipe.

===Initialisation===
'''Préparation et organisation du projet'''
*Répertorier l'ensemble des intervenants
*Définir les objectifs stratégiques du projet
* Évaluer la faisabilité du projet
* Évaluer les moyens nécessaires 
* Établir un accord entre le client et le fournisseur
* Lancement du projet

===Cadrage===
'''Analyse et spécification des exigences :'''
* Définir la hiérarchie des objectifs
* Définir la hiérarchie des fonctions
* Planifier les changements des processus "métier"
* Définir les ressources nécessaires et le cycle de développement
* Valider les objectifs et les contraintes

===Conception===
'''Conception de la solution : '''
*Modéliser :
**Établir une liste détaillée des fonctionnalités
**Créer le modèle de données exhaustif
*Préparer la documentation technique
* Valider la conception d'ensemble
* Choisir les technologies et les valider
* Valider les modèles et le prototype
* Valider les charges et le planning

===Construction===
'''Développement collaboratif et incrémental'''
* Détailler chaque module
* Réaliser (coder) les modules
* Intégrer les modules
* Tester les modules
* Tester l'intégration
* Documenter
Différents modules peuvent être développés en parallèle

===Finalisation===
'''Préparer la mise en oeuvre :'''
* Préparer le système à l'installation
* Rédiger les manuels utilisateurs
* Rédiger le manuel d'exploitation
* Préparer la formation
* Établir le plan de formation
* Établir le plan de démarrage (reprises de données, bascule technique,...)
'''Tester le système'''
'''Démarrer le système :'''
* Établir l'environnement d'exploitation et l'infrastructure du support d'exploitation
* Mettre en oeuvre le plan de démarrage
* Audit du fonctionnement et évaluation des écarts
* Améliorer et optimiser le système
* Former les utilisateurs

==RUP - Rational Unified Process==
Processus itératif et incrémental divisé en 4 phases : 
#Initialisation : définition de l'objectif du projet et préparation d'un contrat de réalisation
#Élaboration : planification du projet, spécification de la solution proposée, proposition d'une architecture de base
#Construction : développement du produit
#Transition : transition du produit chez les utilisateurs.
Ces 4 phases sont elles-mêmes divisées en N itération, à la fin desquelles Il y a une version du produit livrable.

===Workflows===
Étapes à réaliser dans chaque itération :
* Modélisation d'entreprise (entreprise/business modeling)
* Analyse des besoins
* Analyse et conception
* Implémentation
* Test
* Déploiement
* Gestion de changements
* Gestion de projet
* Préparation d'environnement

==XP - Extreme Progamming==
Modèle itératif à deux niveaux :
*'''Itérations de livraison''' - un plan de livraison doit être défini avec le client
**une livraison - une  version opérationnelle du logiciel
**durée de développement - quelques mois
*'''Itérations de développement''' - une fonctionnalité livrable est décomposée en plusieurs fonctions simples :
**développement par binômes
**les utilisateurs participent aux chois des itérations et aux tests
**durée - 2-4 semaines
**résultat - une ou plusieurs fonctions qui peuvent être intégrées dans la version livrable

===Rôles===
*'''Programmeur''' : est responsable de la conception technique et le codage évolutif
*'''Client''' : doit exprimer ses exigences sous forme de scénarios (user stories) et écrire des jeux de tests fonctionnels
*'''Testeur''' : aide le client à élaborer des jeux de test et à les exécuter
*'''Tracker''' : est responsable de la gestion du temps : planification et contrôle
*'''Coach''' : est responsable du soutien technique des membres de l'équipe
*'''Manager / chef de projet''' : les rôles peuvent être combinés : un chef de projet peut réunir les rôles de manager, tracker et coach. 

==SCRUM==

Développement itératif et incrémental, fait référence à l'organisation d'un jeu de rugby : 
* '''avant-jeu''' : préparation, conception de haut niveau du système et son architecture : le périmètre et la base du contenu du système
*'''jeu''' : développement itératif organisé en sprints de 2-4 semaines
*'''après-jeu''' : livraison finale du système, clôture du projet.

===Vocabulaire===
*'''Product backlog'''
Une liste priorisée de besoins et exigences que  veut le client, exprimé dans son vocabulaire et sa terminologie métier, souvent en termes de scénarios (user stories)
*'''Sprint backlog''' 
Une liste de tâches identifiées par l'équipe du projet à réaliser pendant un sprint afin d'implémenter les scénarios sélectionnés pour ce sprint.
*'''Daily scrum'''
Chaque jour on organise une courte réunion (15 minutes) pour fixer et/ou ajuster les objectifs de la journée
*'''Product owner (propriétaire)'''
Représente le client en ce qui concerne les spécifications des exigences et les acceptations
*'''Scrum master (capitaine d'équipe)'''
Anime au quotidien l'équipe de développement, recadre le projet en cas de difficulté. Ce rôle donne lieu à une certification
*'''Team members (les membres d'équipe)'''
Architectes, développeurs, testeurs, administrateurs de  base de données, etc. Les mebres d'équipe disposent d'une certaine autonomie dans l'organisation de leurs travaux.

===User story==
Le scénario est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur. Ces user stories émergent au cours d'ateliers de travail menés avec le Métier, le Client et/ou les utilisateurs.

'''Le modèle de structure d'une User Story'''

* En tant tant que <rôle, personne, user type>
* Je veux <fonctionnalité, tâche, action>
* Afin de <valeur ajoutée, résultat>

'''Exemples :'''

* ''En tant qu'acheteur en ligne, je veux pouvoir ajouter des items à mon panier afin d'enregistrer mes achats que je ne souhaite pas acheter dans l'immédiat.''
* ''En tant qu'utilisateur, je veux réserver une chambre d'hôtel afin de...''
* ''En tant qu'utilisateur, je veux annuler une réservat5ion afin de...''
* ''En tant que recruteur, je veux déposer des offres d'emploi afin de...''
* ''En tant que je une diplômé, je veux déposer un CV afin de...''
* ''En tant que jeune diplômé, je veux supprimer un CV afin de...''


= Annexes =

= Références =