BOURBET Mouloud Génie Logiciel ENSI-2011 1 Analyse et définition des besoins.

Post on 03-Apr-2015

107 views 1 download

Transcript of BOURBET Mouloud Génie Logiciel ENSI-2011 1 Analyse et définition des besoins.

BOURBET MouloudGénie Logiciel

ENSI-2011

1

Analyse et définition des besoins

Introduction

2

Les problèmes qui étaient soumis aux fabricants de logiciel étaient trop complexe (souvent ils n’arrivaient pas a comprendre la nature du problème)

Des fois le système est nouveau et ne dispose pas de modèle automatisé

3

Un processus visant à établir les fonctionnalités du futur système ainsi que les contraintes aux quelles sera soumis le système.

Donc :L’ensemble des informations concernant le

problème doivent être :RassembléAnalysé Définis de manière compréhensible

4

Remarque : différence entre le but et le besoin

But : caractéristique générale que devra vérifier le système mais on ne peut pas tester.

Besoin : caractéristique que devra vérifier le système et qu’on peut tester.

Exemple :But : produire un logiciel agréable a utilisé Besoin : avoir un logiciel qui permet de

manipuler les commandes par menu ou par souris

5

Le document de définition des besoins (Cahier des charges)

C’est le document qui contient des indications pour les phases suivantes du cycle de vie d’un logiciel.

Il comporte un ensemble de propriétés et de contrainte décrite de façon précise et que devra satisfaire le logiciel.

Il doit décrire ce que doit faire le système sans spécifier comment réaliser ces fonctionnalités.

Les besoins doivent constituer un ensemble cohérent et complet.

6

Les critères que doit vérifier un cahier des charges :

Il doit spécifier le comportement externe du système.

Il doit spécifier les contraintes de réalisation.Il doit être facile a mettre à jour.Il doit servir d’outil de référence aux

programmeurs de maintenance.Il doit contenir des indications concernant les

étapes ultérieures du cycle de vie du logiciel.Il doit spécifier les réponses acceptables aux

événements non désirables.

7

La structure d’un cahier des charges : Introduction : elle décrit:

La raison d’être du système,L’environnement du système, Les fonctionnalités du système de manière très

brève, La structure du document, Les notations utilisées.

Matériel : dans cette partie on doit spécifier :Le matériel et les interfaces, si le systèmes

nécessite du matériel spécifique,Les configurations minimales et optimales sur

lesquelles le système peut s’exécuter en cas de matériel standard.

8

Modèle conceptuel : Le modèle doit décrire une vue générale à haut niveau

des fonctions du système ainsi que leurs relations.Remarque : les notations graphiques sont les plus

appropriés pour décrire ce type de modèle.Il contient deux phases:La modélisation du système global.La modélisation des fonctions principales.Les modèles utilisés :Les automates d’état fini;États/transitionsLe diagramme de flux de données

9

Exemple : considérant un système bureautique composé de : Courrier électronique, Tableur, Service de préparation de document, Recherche d’information.

1ière phase : modélisation du système. Utilisateur

Courier électronique

Système de communication

Communication externe

Préparation de document

Recherche d’information

Tableur

Base de données

10

2ième phase : modéliser la fonction courrier électronique

Utilisateur

Lire courrier

Base de données

Sauvegarder courrier

Envoyer courrier

Système de communication

Accuser réception courrier

Classer courrier

Détruire courrier

11

Besoins fonctionnels : C’est la description selon la nature des

services que le système va fournir à l’utilisateur. La notation utilisée peut être :Un langage naturel.Un langage semi formel.Un langage formel. Un mélange entre toutes les autres notations.

12

Besoins en matière de base de données :L’organisation logique des données manipulées par le système et leurs relations doivent être décrites dans cette section.

Besoins non fonctionnels : Les contraintes sous lesquelles le système va

opérer doivent être décrites dans cette partie. Exemple :Contraintes temporellesEspace mémoireReprésentation des donnéesLangage de programmation.

13

Information donnée à la maintenance : Dans cette section on doit décrire :

Les hypothèses fondamentales sur lesquelles est basé le système,

Les changements prévus du fait de l’évolution du matériel, des besoins des utilisateurs…etc.

Et dans les mesures du possible décrire : Les fonctions, et les contraintes particulièrement sujette au changement.

14

Glossaire : Il doit définir et de manière précise et sans

faire des pré supposition sur l’expérience et la formation du lecteur, les termes techniques utilisés dans le cahier des charges

Index : C’est un revois au document.Remarque : Il est préférable d’avoir

plusieurs type d’index : Alphabétique, Par chapitre, Par fonction.

15

SADT (Structured Analysis and Design Technique) : crée en 1976 aux USA.

Définition : est une méthode générale qui cherche à favoriser la communication entre les demandeurs et les utilisateurs d’une part et les concepteurs et les réalisateurs d’autre part.

16

Les concepts fondamentaux du SADT:La modélisation : aborde un système en le

modélisant afin d’obtenir un enchaînement d’action et des données moins complexes que celle de départ.

Démarche d’analyse : SADT est une méthode d’analyse des systèmes selon un approche descendante, modulaire et hiérarchique, on commence par la description la plus générale et la plus abstraite du système représenté par une seul boite, en suite on éclate celle-ci en plusieurs petites boites moins complexe, les petites boites on a leur tours décomposé et ainsi de suite. SADT limite le nombre de nouvelle boite généré a chaque étape entre 3 et 6 pour des raisons d’efficacité.

17

Niveaux d’abstraction : consiste à séparer les 3 niveaux d’abstraction1. niveau conceptuel : répond aux questions

quoi? et pourquoi? 2. niveau organisationnel : répond aux questions

quoi? où? et quand?3. niveau opérationnel : répond à la question

comment?

18

Les modèles du SADTIl est composé de trois éléments

principaux:Le diagramme d’activités (Actigramme)Le diagramme de données (Datagramme)Les conditions d’activation

19

Le diagramme d’activité (Actigramme) : représenté par les boites manipulant les données véhiculé par les flèches.

Actions(Activités)

Données de contrôle

Données

en entré

Données

en sortie

Mécanisme ou support de l’activité

20

Exemple : Actigramme de la fonction calculer

Calculer

Type d’opération

Opérandes

Résultats

Méthode de calcul Calculateur

21

Le diagramme de données (Datagramme) : également représenté par des boites où les flèches sont cette fois les activités qui créent et utilisent les données

Nom de la donnée

Activité de contrôle

Activités génératrices Activités

utilisatrices

Mécanisme ou support de données

22

Exemple : de passation de paramètre

ParamètreSaisir Afficher

Sélectionner le type d’opération

Registre du calculateur

23

Les conditions d’activation :Syntaxe :N° boite /N° Activation Précondition →

Postcondition Exemple

1 / 1 E1 et C1 → S1 ou S2 et ! C1 : le module modifier n’et disponible en sortie e l’activité « modifier » que si il n y a pas d’erreur détecté.

2 / 1 E1 et C1 → S1 ou S2 et ! E1 : le module testé en sortie de l’activité « tester » implique q’il n’est plus en entré de « modifier ».

Modifier (1)

Tester (2)

E1

S2

E1

C1S1

C1

S1

Module testé

Jeu de teste

Module testé

Erreur détectée

Module

Nmbr d’erreur > 0