Les Projets SI : le développement d'un système

12 novembre MMX
  • Projets
  • Différents modèles de développement
  • Besoins

Rappels sur le cours précédent

Introduction

Rappel : un produit ou service de qualité est un produit dont les caractéristiques lui permettent …

L'assurance de la qualité
Le contrôle qualité

est un aspect de la gestion de la qualité. Le contrôle

ISO 9001

  1. Démontrer l'aptitude à fournir régulièrement un porduit onforme aux exigence du client et aux exigence réglementaires applicables.
  2. Chercher à accroître la satisfaction des clients…

ISO 9001-2008 -- 8 principes

  1. orientation client
  2. implication de la direction (leadership)
  3. implication du personnel
  4. approche processus
  5. approche système (interaction des processus)
  6. amélioration continue
  7. prise de décision factuelle
  8. relation mutuellement bénéficiaires avec les fournisseurs

ISO 9126 Qualité des produits logiciels

Caractéristiques :

  • capacité fonctionnelle
  • fiabilité
  • facilité d'usage
  • efficacité
  • maintenabilité
  • portabilité

Gestion des projets

un projet

un engagement irréversible de résultat incertain, non reproductible a priori à l'identique, nécessitant le concours et l'intégration d'une grande diversité de contribution, et répondant à un besoin exprimé.

Un projet a pour objet d'utiliser le plus efficacement possible les ressources humaines et techniques disponibles, afin d'apporter un nouveau service ou un produit précis, dans un environnement donné et avec un budget donné.

Groupe de ressources principalement matérielles et humaines, qui sont combinées pour la réalisation d'activités et de tâches, avec un coût et une durée de temps…

Un projet est un processus unique qui consiste en un ensemble d'activités coordonnées et maîtrisées, comportant des dates de début et de fin, entrepris dans le but d'atteindre un objectif conforme à des exigences spécifiques, telles que les contraintes du délai, de coûts et de ressources. 1)

Types AFITEP de projet informatique

  • progiciel applicatif : mise en place d'un progiciel du marché
  • développement applicatif : développement spécifique à une entreprise
  • intégration des systèmes : assemblage de différents logiciels
  • maintenance évolutive : nouvelle version d'un logiciel existant
  • infrastructures techniques : mise en place de systèmes d'infrastructure (par exemple réseau)

D'autres classements existent

  • stratégie
    • enjeux de niveau DG
    • technologie novatrice
    • ex. : e-commerce, EDI
  • efficience
    • amélioration productivité
    • technologie éprouvée
    • ex. : progiciel de paie, gestion de stock
  • obligation
    • obligation extérieure, réglementaire, de fait ou imposée
    • technologie banalisée
    • ex. : An 2000, euro, fusion
Maître d'ouvrage

dans le contexte d'un projet de système d'information, ce terme a été emprunté au vocabulaire du bâtiment de des travaux publics : maître d'ouvrage est celui qui commande (et qui paie) l'ouvrage à construire (par exemple la Direction de l'enseignement commande la construction d'une nouvelle cécole). C'es le client.

Maître d'oeuvre

dans le … c'est le chef de projet

Triangle du projet :

  1. qualité ou performance
  2. délais
  3. coûts
échantillon de 365 entreprises et 8 380 projets
16 % sont des succès
31 % sont arrêtés en cours de réalisation
53 % aboutissent mais au prix d'un accroissement du délai et du coût tout en offrant moins de fonctionnalités que prévu, le multiplicateur étant en moyenne 2.89 pour le coût et 3.22 pour le délai.

Facteurs d'échec

  • expression de besoin initiale confuse
  • priorités non définies, moyens inadaptés, pouvoir du chef de projet
  • spécifications relevant de la science fiction plus que du réalisme du métier ou de la technique
  • versatilité, instabilité de la demande ou caractère inflationniste de la demande
  • insouciance en ce qui concerne la conduite de projet
  • mauvaise gestion des risques
  • évaluation initiale trop faible
  • manque de compétence des acteurs

Facteurs de succès

  • chef de projet professionnel et expérimenté
  • implication des utilisateurs, travail collaboratif
  • implication et soutien fort de la direction
  • accompagnement au changement, communication
  • une envergure limitée aux besoins essentiels
  • une infrastructure technologique normalisée
  • des spécifications précises et stables
  • des méthodologies formelles et utilisées
  • des estimations fiables et rigoureuses

Gérer un projet c'est

  • une activité à part entière (gérer le projet ce n'est pas développer un système)
  • une activité composée de taches spécifiques et utilisant des outils spécifiques…produisant des livrables spécifiques
  • une activité basée
    • sur l'anticipation (vison vers le futur), prévoir, planifier
    • sur le suivi (tirer des lecons du passé) afin de mieux plainifier
    • sur une gestion au quotidien (réaction aux problèmes ou évènements)
    • Plan (planifier), Do (exécuter), Check (suivre vérifier), Act (améliorer)…s'applique aussi!

(14) Les phases d'un projet

1. Phase préalable
Démarrage
3. Planification
Ordonnancement
5. Mise en exploitation
2. Définition 4. Exécution 6. Clôture

1. Phase préalable et démarrage

  • Etude d'opportunité et de viabilité
  • Calcul prévisionnel de retour sur investissement (ROI)

2. Phase Définition

  • périmètre, contexte
  • équipes, responsabilités
  • découpage fonctionnel (WBS, Work Breakdown Structure)
  • étude d'impacts, identification des facteurs de risques et des facteurs d'échec

3. Planification / Ordonnancement

  • Définition du plan d'exécution en termes de délais, de ressources et de responsabilité

4. Exécution

  • Exécution et pilotage du projet, suivi du franchissement des jalons, gestion des dérives, importance de la réunion de travail projet.

5. Mise en exploitation

  • Recette, vérification des conformités, mise en exploitation, formation, poursuite de l'accompagnement du changement.

6. Clôture

  • Élaboration de la documentation dans une démarche de transfert de la connaissance.
  • Gestion des évaluations du projet, préparation des évolutions.

Phases (3)

Prise en charge : Délimiter → Structurer → Estimer → Planifier →

Plan projet PAQ

Conception Réalisation Mise en oeuvre
Suivre et gérer les équipes
Controler / Valider / Assurer la qualité Terminer
Documenter / Informer / Communiquer

(18) Les Cycles de développement

(19) Le modèle en cascade

Repose sur les hypothèses suivantes

  • on ne peut pas construire la toiture avant les fondations
  • les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts en aval (on peut imaginer la fabrication d'un moule dans l'industrie du plastique )
  • les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle. Le processus de développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques :
    • produire des livrables définis au préalable
    • de se terminer à une date précise
    • de ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de validation-vérification.
  • analyse des exigences
  • design du système
  • programmation
  • programmation
  • test unitaire et d'intégration
  • test du système
  • test d'acceptance
  • maintenance

Cycle en V

analyse des besoins recette
spécifications tests de validation
tests d'intégration
tests unitaires
codage

modèle en W : variant du modèle en V, avec prototype, recette de maquette en phase besoins

Modèle incrémental

  • expression des besoins
  • spécif fonctionnelle
  • conception du système
  • deux ou plusieurs branches, des sous-systèmes
  • ⇒ risques d'incohérences, double travail

Modèle itératif

on ne planifie plus les versions en avance, on refait un nouveau cycle complet à chaque nouveau besoin.

Modèle en spirale

hyper compliqué, faut voir le dessin. Analyses de risques fréquentes.

R.A.D.

encore un dessin nécessaire. 120 jours maximum

Prototype vs maquette

  • maquette : montre l'enchainement des différents écrans. une maquette papier est tout à fait possible (peut être statique)
  • prototype : diffère du produit final par le processus de conception. mais une vraie partie du système.
Avantages Inconvénients
Cascade logique
facile à comprendre
retour en arrière difficile
peu évolutif
effet tunnel
est-on capable d'établir tous les besoins en début de projet?
Cycle en V logique
facile à comprendre
validations à chaque phase
retour en arrière difficile
évolutions couteuse
évaluation utilisateur tardive
Cycle en W + intégration de l'utilisateur par maquettage retour en arrière difficile
évolutions couteuse
Cycle incrémental délivre assez rapidement quelque chose de visible Risque d'être figé
Mise en cause du noyau?
itératif feedbacks utilisateurs rapides
adapté aux changements
risque de remise en cause
risque d'impossibilité technique d'intégrer nx besoins
necessite de disposer des compétences à chaque iteration
confusion maquette et solution
jamais fini?
R.A.D. résultats rapidement
implication utilisateur
implication utilisateur
risque de blocage …

Cycle en V

Analyse des besoins et faisabilité

  • C'est une activité primordiale
  • Comprendre l'activité future…avec le système qu'on va mettre en place :
    • faire l'inventaire des personnes (services) concernées directement ou indirectement, voire dans le futur, mais aussi des systèmes adjacents
    • faire des scénarios (use cases, mais aussi des évènements externes)
  • Différentes catégories
    • besoins fonctionnels : ce” que le système doit faire (pas une réponse)
    • besoins non fonctionnels : propriétés attendues (par exemple besoins en performance), maintenance, interface utilisateur, sécurité, légaux, environnementaux
    • critères de réussite –mesurables! …très importants
  • identifier les acteurs, le contexte
  • identifier les contraintes réglementaires

Exemples de besoins

  • opérationnel 24/24, 7/7
  • pouvoir supporter 50 utilisateurs
  • afficher les prévisions météo
  • mobiles doivent résister à une chute
  • système doit comporter une aide en ligne
  • doit fonctionner même si périphérique d'impression sont en panne

Comment caractériser un besoin

  • identifiant unique
  • description textuelle
  • raison/justification
  • origine : qui a demandé ça?
  • critères de réussite
  • satisfaction : combien c'est utile à l'utilisateur
  • insatisfaction : combien c'est indisponsable
  • documents de référence
  • priorité
1) ISO 10006
 
m2ilc/qualite_2.txt · Dernière modification: 2010/11/12 12:19 par suitable
 
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante :CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki