CM5
Cycle de vie logiciel + CdC ?
- part d'un besoin / répondre à un besoin.
-> mais entre ce qui est demandé, spécifié, réalisés, et après test, différence.
Système + frontière du système (ses interactions avec l'extérieur).
- une composition de sous-systèmes/composants.
Différence quoi/comment:
- desc. fonctionnelle.
- desc. technique
-> exigences fonctionnelles et techniques.
-> enfermer dans un écosysteme.
Système : solution répondant à un problème.
- logique: resp. client (ce dont il a besoin)
- technique: resp. du developpeur (comment il va faire)
Logiciel: produit spécifiques
Progiciel: produit généraliste
- ERP (Entreprise Ressource Planning)
- CRM (Customer Relationship Management)
- SCM (Supply Chain Management)
- gestion RH.
-> interaction de ces systèmes ?
Logiciel stable:
- technologiquement
- métier (besoins évoluent)
- nouveaux besoins
Logiciel = cher.
- rentable sur temps long.
- dette technique.
- notion de version.
- maintenance évolutive (new version) ou correctives (bug fix).
- garantir stabilité logiciel entre 2 versions.
- suivi/traçabilité des modifications.
MOA : maîtrise d'ouvrage
- client: formalise/spécifie le besoin
- défini objectifs plannings et budget
- accompagne l'utilisateur dans le déploiement.
MOE : Maîtrise d'oeuvre
- prestataire: conception et construction de la solution technique.
- identification et planificaiton des tâches
-> livrable, conditionner payements au livrable / échellonner
=> Notion de CdC : contrat entre MOA/MOE.
-> appel d'offre.
Objectif projet
- planning
- coût
- périmètres.
=> ressources / GANTT.
-> plannings pas tenus logiciels -> sous-estime temps.
Avant projet / kick-off (go-no go) - première gestion de risque (probabilité d'échecs, coûts, etc).
- transformer idées en enjeux quantifiable/qualifiable
-> que signifie la "réussite" du projet ?
-> objectifs/budget/délais.
- investissement expliquer la rentabilité + ne pas perdre de l'argent.
Besoin vs solution
- client peut avoir tendance à exprimer une solution au lieu de son besoin.
- comprendre ses motivations, pourquoi il veut. quelle utilisation.
- ne comprend pas nécessairement la réalisabilité (ou non) de ce qu'il demande.
répondre à la demande != faire ce qu'il demande.
Recueillir le besoin sans préjuger des solutions techniques.
Comment s'intègre au SI (dont inter logiciels...) / processes + capacités/limités du SI.
- prendre en compte les utilisateurs finaux (dont ergonomie...)
- classer demandes par priorités
- indispensable.
- HS
- Périmètre fonctionnel du projet
- lister et organiser les grandes fonctionnalités.
- + les évaluer.
- processus métiers dans lequel il s'intègre ?
- flux + acteurs.
-> comment évaluer = tests (#85)
- test recette utilisateur <= besoin
- test recette fonctionnelle <= conception générale.
- test d'intégration (ça rentre dans le SI ?)
- test unitaires.
#96
- fonctionnelle
- règlementaires
- disponibilité
- interface
- performance
- sécurité
- ergonomie
- maintenabilité
[acceptation utilisateur ?]
===== Env. 1H...
- Réorganiser...
=> W7 en W6 + fusionner avec git ?
=> + prévoir exo...
=> analyser et formaliser ensemble de demandes clients (pas forcément des besoins ?
=> constuire CdC étapes par étapes.