Rédaction du Document de Spécifications Logiciel
-
Instruction Générale Qualité
|
Page de service
Historique des évolutions
Version
|
Date
|
Auteur
|
Pages/parties modifiées
|
Description
|
1.1
|
26/03/2004
|
FBA
|
Toutes
|
Ce document a été établi à partir d’éléments initialement rédigés par Arnaud Deromas pour la Junior Entreprise EDIS (http://www.fiifo.u-psud.fr/Actu/Initiatives/EDIS.htm). Ils ont été adaptés aux mini-projets proposés dans l’UV UMLP.
|
1.1
|
25/02/2005
|
FBA
|
Toutes
|
Refonte pour le semestre 2005P
|
Suivi des diffusions
Entité
|
Nom
|
Etudiants de l’UV UMLP
|
tous
|
Intervenants de l’UV UMLP
|
tous
|
|
Nom et qualité
|
Date et visa
|
Auteur :
|
FBA
|
le :
|
Vérificateur :
|
FFI
|
le :
|
Approbateur :
|
|
le :
|
Documents associés
Document
|
Référence
|
Manuel Qualité du mini-projet UMLP
manuel_qualite.doc
dans :
http://asi.insa-rouen.fr/enseignement/siteUV/genie_logiciel/referentiel_qualite/
|
[MQ]
|
Sommaire
Sommaire 3
1 Introduction 4
2 Domaines d’application 5
3 Contenu du DSL 6
4 Annexe : Exemple de cas d’utilisation rédigé 11
1Introduction
L’Instruction Générale Qualité de Document de Spécifications Logiciel décrit ce qu’il est nécessaire d’indiquer dans un Document de Spécifications Logiciel (DSL).
Le présent document doit être pris comme un guide d’utilisation destiné à aider à la rédaction d’un DSL. Ce document est adapté au cadre du mini-projet de l’UV UMLP. Il permet de comprendre, chapitre par chapitre, ce qui doit figurer dans chacun des chapitres de ce document.
Ce document peut servir de base éventuellement dans d’autres organisations (au cours d’un stage, de votre vie professionnelle ou associative, …) qui ne disposeraient d’une telle formalisation de leur processus. En revanche, les étudiants doivent être conscient que chaque organisation ou contexte de développement (PIC, projet MGPI, …) est libre de définir des document-types alternatifs, avec une structure et des modèles d’organisation complètement différents.
2Domaines d’application
L’Instruction Générale Qualité de Document de Spécifications Produit s’applique à tout produit qui suit les plans de développement légers, développés de manière itérative dans le cadre de l’UV UMLP.
3Contenu du DSL
Chacun des sous chapitres qui vont suivre correspond à un chapitre d’un DSL. Ainsi, le chapitre 3.1 décrit le chapitre 1 d’un DSL. Le chapitre 3.2.1, décrit le chapitre 2.1 d’un DSL. Certains chapitres pourront être omis, en fonction de leur pertinence en rapport avec le domaine étudié. Si des artefacts ne peuvent être insérées dans des chapitres, ils doivent être reportés en Annexe.
3.1Introduction
L’introduction se décompose en cinq sous chapitres qui ont pour but de présenter globalement le projet développé sans entrer dans le détail des spécifications.
3.1.1Objectifs du document
Préciser l’objet de ce document et son audience.
3.1.2Champ d’application
Identifier très clairement le produit à développer en lui donnant un nom. Exemple : site de commerce en ligne, infocentre, didacticiel…etc. Expliquer ce que fera et éventuellement ce que ne fera pas le produit. Dire à quoi va servir le logiciel, ce qu’il va apporter de bénéfique.
3.1.3Organisation du document
Expliquer comment le DSL est organisé, et tout particulièrement quelle organisation prévaut pour le chapitre spécifications détaillées (chapitre 3 du DSL).
3.2Description globale
Tous les facteurs pouvant influer sur le produit et sur le respect des exigences sont recensés ici. On n’aborde pas encore le détail des spécifications, mais on décrit le contexte dans lequel le logiciel sera insérer.
Préciser dans ce paragraphe l’environnement d’exploitation et d’utilisation des matériels et logiciels (profil des machines, système d’exploitation, lieu d’installation et d’exploitation, protocoles…).
3.2.1L’environnement du produit
Si le logiciel est imbriqué dans une entité plus générale, ou s’il reçoit des données en provenance d’autres systèmes ou qu’il envoie des données vers d’autres systèmes, il sera sans doute utile d’inclure un diagramme de déploiement (au sens UML), voire un diagramme de composants (au sens UML) pour représenter ces interactions.
3.2.2Interfaces utilisateur
Description des interfaces utilisateur. Exemple : taille des écrans, disposition des objets graphiques, activation ou non de certaines touches de fonctions…
Si il y a différents profils d’utilisateur on peut aussi expliquer le comportement de l’application en fonction de ces profils.
3.2.2.1Interfaces matérielles
On décrit comment le logiciel s’adapte au matériel sur lequel il tourne. On peut définir la portabilité du logiciel sur différents système d’exploitation ou simplement prévoir comment il s’adapte à des machines configurés avec des périphériques différents.
3.2.2.2Interfaces logicielles
Le logiciel peut s’interfacer avec d’autres logiciels. Il peut s’agir de logiciels « maison » ou de logiciels achetés sur étagère. Dans tous les cas, la liste de ces logiciels et leurs caractéristiques précises (nom, n° version/release) doit figurer dans ce paragraphe.
Décrire l’architecture réseau sur laquelle s’appuie le logiciel, quelles sont les protocoles utilisés et reporter ces informations de manière graphique sur l’éventuel diagramme de déploiement du chapitre 2.1 (« L’environnement du produit »).
3.2.2.4Environnement opérationnel
A quel moment effectue t-on les sauvegardes ? Y a t-il des périodes où le logiciel est plus sollicité ? Quelle est l’organisation des utilisateurs ?
3.2.3Fonctionnalités du produit.
Représentation des principales fonctions assurées par le logiciel. En particulier on doit faire apparaître les évènements externes ou internes qui provoquent l’activation des fonctions. Le formalisme du diagramme des cas d’utilisation est approprié. Les cas d’utilisation les plus pertinents feront l’objet d’une description pas à pas dans la section suivante (3. Spécifications détaillées) à l’aide d’une ou plusieurs technique : description textuelle, diagramme d’activité, diagramme de séquence système.
3.2.4Profil des utilisateurs.
Description des compétences et du niveau d’expérience des utilisateurs.
3.2.5Contraintes de développement
On décrit ici globalement tous les éléments à prendre en considération par les équipes de développement lors du choix des options techniques. Ces éléments concernent généralement :
-
les normes et législations particulières applicables.
-
Les limitations liées au matériel.
-
Les interfaces avec d’autres applications.
-
Le niveau de fiabilité demandé.
-
le niveau de sécurité demandé.
3.2.6Hypothèses et Dépendances
La possibilité de réaliser certaines exigences peut être soumise à conditions, ou dépendre d’éléments bien précis. Il faut énoncer ici ces éléments et ces conditions.
3.3Spécifications détaillées
Description détaillée des fonctionnalités du logiciel à l’aide de cas d’utilisation. Chaque fonctionnalité peut être éclatée en plusieurs cas d’utilisation (sous-fonctionalités), elles-mêmes décomposées… Un sous chapitre par cas d’utilisation. Un exemple de cas d’utilisation est proposé en Annexe.
3.3.1Cas d’utilisation 1
Pour chaque cas d’utilisation, on trouve les chapitres suivants:
3.3.1.1Titre 3.3.1.2Résumé 3.3.1.3Acteurs 3.3.1.4Pré-condition(s) 3.3.1.5Action Déclencheur 3.3.1.6Scénario nominal
Action du (des) acteur(s)
|
Action du système
|
|
|
|
| 3.3.1.7Action de fin 3.3.1.8Post-condition(s) 3.3.1.9Exceptions 3.3.1.9.1Remarques ergonomiques (éventuellement) 3.3.1.9.2Contraintes non fonctionnelles (éventuellement) 3.3.2Cas d’utilisation 2
….mêmes chapitres que pour le Cas d’utilisation 1
3.3.3Contraintes imposées à la conception
3.3.3.1Conformité aux règles et standards en vigueur chez le client
Il peut s’agir du format des états, de conventions de nommage des données, de méthodes de mesures ou d’audit.
3.3.3.2Caractéristiques mesurables exigées
Le client peut exiger que le logiciel livré possède des caractéristiques mesurables très précises. Les caractéristiques les plus souvent rencontrées sont exposées ci-après.
3.3.3.2.1Sûreté du système
Les méthodes pour déterminer comment mesurer la sûreté du système sont exposées ici.
3.3.3.2.2Disponibilité du système
Les méthodes pour déterminer comment mesurer la disponibilité du système sont exposées ici.
3.3.3.2.3Sécurité
On trouvera la description de méthodes de sécurité telles que le cryptage des données, la restriction des communications entre certaines parties du logiciel, la conservation de fichiers journaux (log) ou historiques.
3.3.3.2.4Maintenabilité
Le client peut exiger d’avoir un logiciel facile à maintenir. Il peut demander, par exemple, qu’on lui livre un logiciel très modulaire, doté d’interfaces normalisées, ou de limiter le niveau de complexité des fonctions (en limitant le nombre de sous programmes appelés, par exemple).
3.3.3.2.5Portabilité
Le client peut exiger d’avoir un logiciel plus ou moins portable. Les caractéristiques mesurables de cette portabilité peuvent être :
-
Le pourcentage de composants dépendants de la machine d’exploitation.
-
Le pourcentage de lignes de code dépendants de la machine d’exploitation.
Le client peut aussi exiger l’utilisation d’un langage réputé portable, d’un compilateur bien précis, ou d’un système d’exploitation.
3.4Description des fournitures
Préciser de façon exhaustive, quels sont les documents et matériels qui doivent être remis au client au moment de la réception des prestations (Manuel Utilisateur, Exécutable, Code source, CDROM, l’ensemble du référentiel de développement…).
3.5Annexes
Inclure ici les annexes.
On trouvera ici des artefacts très variées allant de l’échantillon de formulaires utilisés dans le système ou l’organisation existante, en passant par des compte-rendus de réunion, de rencontre avec la maîtrise d’ouvrage. Ne pas hésiter à joindre tout document pouvant aider le lecteur à mieux comprendre le DSL.
4Annexe : Exemple de cas d’utilisation rédigé
Domaine : Système de gestion d’une bibliothèque
Titre: Emprunter ouvrage.
Résumé: Liste des actions réalisées par un étudiant se présentant pour emprunter un ouvrage dans la bibliothèque.
Acteurs : Etudiant (E), Hôtesse (H)
Pré-condition(s):
L’étudiant est inscrit à la bibliothèque
L’étudiant a trouvé son ouvrage dans les rayons de la bibliothèque
Déclencheur:
0. L’étudiant souhaite emprunter le livre qu’il a en main.
Scénario nominal
Action du (des) acteur(s)
|
Action du système
|
1. E se présente à l’accueil
|
|
2. H récupère les coordonnées de l’ouvrage
|
3. Le système (S) signale si l’ouvrage est dispo (Exception A)
|
4. H demande la carte d’inscription à la bibliothèque
|
5. S vérifie la validité de la carte (Exception B)
|
|
6. S indique la date de retour
|
7. H précise la date de retour et demande confirmation
|
|
8. E confirme son intention de retirer le livre
|
|
9. H valide l’emprunt
|
|
Action de fin:
10. E quitte l’accueil avec son ouvrage.
Post-condition(s):
L’ouvrage n’est plus disponible pour un autre prêt.
Exceptions:
Exception A : L’ouvrage a été réservé
H signale la non-dispo de l’ouvrage,
H invite l’étudiant à revenir à la date d’expiration de l’emprunt.
E se retire.
Exception B : La carte n’est pas valide ou l’étudiant est banni pour quelques jours car il a rendu son précédent emprunt trop tard.
H précise les causes du refus de prêt
E se retire.
Remarques ergonomiques
H pourra utiliser une douchette (lecteur de code barre) pour récupérer les coordonnées de l’ouvrage.
Contraintes non fonctionnelles
Type de contrainte
|
Descriptif
|
Temps de réponse
|
Les différentes requêtes doivent prendre moins de 3 secondes
|
Fréquence
|
On peut compter une dizaine de consultation de ce type dans une heure de travail de H
|
Volumétrie
|
Le nombre de livres est de l’ordre de 100 000 titres.
Le nombre d’inscrits à la bibliothèque est de l’ordre de 5000 personnes.
|
Disponibilité
|
Cette fonction doit être opérationnelle dans les heures d’ouverture de la bibliothèque
|
Concurrence
|
Non applicable. Dans la mesure où l’étudiant présente le livre, aucune autre personne ne peut demander des infos sur un même enregistrement de livre.
|
Intégrité
|
Non spécifique.
|
Confidentialité
|
Non spécifique.
|
Version : 1.1
|
|
Nombre de pages :
|
Référence : referentiel_qualite/DSL.plan_type.doc
|
UV UMLP
Département ASI – INSA-ROUEN
BP 08 – Avenue de l’Université
76801 SAINT-ETIENNE-DU-ROUVRAY Cedex
Dostları ilə paylaş: |