This website works better with JavaScript
Inicio
Explorar
Ayuda
Iniciar sesión
jdehos
/
cours_projets_l3_old
Seguir
1
Destacar
0
Fork
0
Archivos
Incidencias
0
Pull Requests
0
Wiki
Árbol:
df6c22d087
Ramas
Etiquetas
master
cours_projet...
/
CM3
/
CM3.md
CM3.md
5.0 KB
Histórico
Raw
title: "Projets, CM3"
date: 2016-05-18
Dernières étapes d’un projet informatique
Problématique
le projet ne termine pas à l’écriture de la dernière ligne de code
il reste encore à effectuer/terminer d’autres étapes avant de livrer le projet
conseil : mieux vaut un logiciel partiel bien validé/livré qu’un logiciel complet mal validé/livré
d’où l’importance de planifier/suivre le projet pour voir si on peut finir dans les délais ou s’il faut sacrifier des spécifications
## Étape de validation
objectif : vérifier que le logiciel répond aux spécifications
comment ? $\rightarrow$ tests unitaires, cas d’utilisation, ...
évidemment on valide régulièrement au cours du projet mais il faut tout revérifier sur le logiciel final
Documentation
objectif : expliquer comment utiliser le logiciel et comment maintenir le code source
types de doc :
commentaires de code
manuel d’installation
manuel d’utilisation
documentation de maintenance
certaines documentations sont faites pendant le développement mais d’autres nécessitent d’avoir le logiciel à peu près fini
## Release
quoi-qu’est-ce : le logiciel final avec tout ce qu’il faut pour pouvoir l’utiliser
forme : une archive tar gz (par exemple) ou un tag dans le système de gestion de versions
contenu :
selon le CDC : code source avec script de compilation/installation ou binaire compilé pour les plates-formes prévues
documentation
éventuellement : fichiers de configuration, données d’exemple, ...
Autres étapes possibles
déploiement (installation chez le client, migration de données...)
formation des utilisateurs, assistance technique
maintenance (correction de bugs, ajout de fonctionnalités)
## Bilan
faire la synthèse des spécifications et de la planification réellement obtenues
comparer avec les prévisions initiales
faire le bilan de ce qui a fonctionné ou non et y penser pour les prochains projets
Rapport de projet
Le rapport de projet dans la vraie vie
bilan pour garder une trace (archives) et pour progresser (projets futurs)
complété par la documentation (installation, utilisation, maintenance)
Le rapport de projet à la fac
savoir présenter le travail réalisé (clairement et objectivement)
savoir prendre du recul
Public visé par le rapport
connait le domaine (développement informatique)
mais pas le projet ni son contexte
importance d’être synthétique et clair
Contenu
présentation du projet :
contexte
besoins
spécifications demandées
l’état du produit (logiciel) au début du projet
réalisation :
présentation du logiciel réalisé
présentation technique (architecture générale, points importants)
bilan :
déroulement du projet (prévisions, problèmes rencontrés, solutions, ...)
résumé des objectifs réalisés (ou pas)
conclusion pour les projets futurs
Forme
document PDF (cf
template fourni
)
texte + illustrations (captures écrans, UML, schémas, ...)
pas de code source
faire simple, concis et structuré
corriger l’orthographe et la conjugaison
Soutenance de projet
## Objectif
idem rapport : présenter projet et résultats
même type de public : connait le domaine mais pas le projet
forme différente : oral + support
## Contenu
similaire au rapport :
présenter le projet et la demande
travaux réalisés
bilan, conclusion
soigner introduction/conclusion (progression, prise de recul)
présenter tous les travaux mais n’en détailler que quelques uns
Forme (classiquement)
15 minutes (maximum) de présentation + questions
accès à un vidéo projecteur + ordinateur
si PC portable perso, être sûr du multi-écran et de la batterie
Quelques conseils sur les slides
limiter le nombre de slides à un par minute max
ne pas surcharger un slide : liste des idées à exprimer et/ou illustrations
« un bon schéma au lieu d’un long texte »
sur chaque slide : titre de la présentation, auteurs, numéro du slide
toujours prévoir une version PDF sur clé USB au cas où
éviter les animations inutiles !
Quelques conseils sur la démonstration
objectif : montrer le logiciel en train de fonctionner
intéressant si aspect dynamique particulier ou pour éviter la monotonie
démo en direct dangereuse, vidéo pré-enregistrée plus sûre
prévoir/structurer/commenter ce qui est montré
Quelques conseils pour l’oral
rester objectif : ne pas sur-vendre le travail, ni le dévaloriser
éviter la feuille anti-sèche (les slides doivent suffire)
plusieurs orateurs : bien répartir, ne pas se couper/contredire
faire une répétition
(voire plusieurs)
Travail à réaliser
À la fin du projet
livrer le projet (release propre et complète)
rendre un rapport
faire une soutenance