Quel est le cycle du développement logiciel?
Client -> Vision & Requis -> Architecture -> Conception -> Codage -> Intégration -> Déploiement -> CLIENT…
L’assurance qualité est un processus continu qui englobe toutes les phases de développement.
Quelles sont les attentes pour le développement logiciel?
- Produire un logiciel de qualité
- Terminer avant la date limite
- Il faut que ça ne coûte pas trop cher
- Il faut que ça se passe agréablement
- Il faut que le logiciel reste en ligne en tout temps
- On veut recevoir du feedback concret des usagers en tout temps
Quelles sont les “Qualités” d’un logiciel?
- Qualité en utilisation : Nombre de bogues (Tests et corrections des erreurs), répond au besoin des clients (rencontre), facilité d’utilisation (prototypes d’interface)
- Qualité du produit : Maintenabilité (Design flexible au changement), tolérance aux pannes (mécanisme de gestion des erreurs), Sécurité (Revues de code pas un expert)
- Qualité des données : Traçabilité des données (Suivi post-livraison), portabilité des données (Fonctionnalités d’expostation), etc
Comment s’assurer de bien utiliser les ressources?
- Planifier un effort constant tout au long du projet ( ex : Paralléliser les activités)
- Planifier des activités de complexités égales (ex: design modulaire du code)
- Limiter les heures supplémentaires et le crunch (ex : Cycle time fixe et court)
- Répartir les responsabilités de chacun (définir les compétences de chaque rôle)
- Prévoir les activités d’opérations dès l’implémentation
À quoi servent les processus?
Communication (interne et externe), évaluation des pratiques internes (diagnostic et amélioration) et planification du travail (haut niveau et orienté produit).
Quel est le but d’un SRS traditionnel?
Le SRS traditionnel a pour but de servir de dépot pour toutes les exigences du logiciel.
Le SRS transforme les besoins flous et abstrait des parties prenantes (stakeholders) en fonctionnalités concrètes et mesurables.
Les exigences des SRS traditionnels sont utilisés pour quoi?
- Définir la portée du projet
- Fractionner le projet en paquetages
- Servir de base pour l’analyse et la conception
- Définir les tests de validation
- Rédiger le contrat avec le client
Que sont les exigences fonctionnelles?
Ce sont des exigences qui décrivent les fonctionnalités du produit logiciel.
Que sont les exigences non-fonctionnelles?
Ce sont des exigences qui décrivent les qualités du produit logiciel.
Comment déterminer si c’est une fonctionnalité ou une qualité?
Règle du pouce:
- Si ça peut être construit durant une tâche bien définie, c’est une fonctionnalité.
- S’il s’agit de quelque chose à surveiller durant une bonne partie du projet, c’est une qualité.
Qu’est ce que la norme IEEE 830?
C’est une norme qui définit un gabarit standard pour la structure du SRS.
Pourquoi les exigences doivent-elles être compréhensibles par tout le monde?
Parce qu’elles peuvent être lues par des gens qui ne connaissent pas toujours le domaine.
Quelles sont les qualités d’un document SRS complet?
- Complétude : Tous les besoins exprimés sont là.
- Correct: Pas d’exigences superflues.
- Cohérence interne: Pas de contradiction entre exigences.
- Cohérence externe: Pas de contradiction avec les documents externes fournis.
- Traçabilité: Numéro unique pour chaque exigence.
- Organisation : Faciliter la recherche d’information.
- Concision: Niveau de détail adéquat.
- Ambiguîté (ou plutôt non-ambiguîté): Définir un glossaire et réutiliser toujours les mêmes termes.
- Redondance: Comme pour le code, à éviter le plus possible.
Comment s’assurer de respecter les dates limites?
- Planifier chaque étape du projet (ex: Jalons intermédiaires)
- Baser les estimations sur ce qu’on sait des projets précédents (ex: Collecte de données de projets en cours)
- Toujours avoir un produit fonctionnel (ex: Intégration continue)
- Mise en production fréquente (ex: Livraison continue)
- Connaître l’avancement de chacun (ex: Réunions de suivis)
- Prévoir les imprévus (ex : Planifier les alternatives)
Quelles sont les qualités des exigences individuelles?
- Qualité de la langue : Syntaxe et grammaire.
- Structure d’écriture : Le doit …
- Utilisation du pluriel : Attention aux ambiguités.
- Utilisation du négatif: À éviter le plus possible.
- Éviter les exigences composées.
- Les exigences doivent être testables.
- Indépendance du design.
- Les exigences doivent être faisables.
