Hiver 2011 SEG2506 - Chapître 1 1

Chapître 1 (partie 1)

Revision de cours précédants

Sujet 1:

Le processus de développement de logiciel

Hiver 2011 SEG2506 - Chapître 1 2

Des problèmes …• La qualité et le coût du logiciel laisse à désirer

– Livraison en retard– Coût plus grand que prévu– Sans donner la satisfaction anticipée aux usagers

• Types d’erreurs:– Planifier une fonctionnalité en désaccord avec le but du

système– Définir une fonctionnalité inconsistante à l’interne– Implanter la fonctionnalité différente que planifié

Hiver 2011 SEG2506 - Chapître 1 3

Raisons

• Il est difficile de comprendre le but du système assez bien pour planifier sa fonctionnalité au début et donner complète satisfaction aux usagers.

• La complexité du système et de son comportement dynamique est trop grande.

• La nature de visibilité du produit rend l’effort de développement et de maintenance difficile à comprendre et à contrôler.

• Il y a un manque de composantes éprouvées qui peuvent servir comme modules réutilisables. Il y a trop de re-développement.

Hiver 2011 SEG2506 - Chapître 1 4

Qualité du système

• La qualité du système est son habilité de satisfaire les besoins et attentes des usagers et propriétaires.

• La qualité dépend d’une bonne communication (précise et sans ambiguïté) pendant le développement du système (voir diagramme).

Hiver 2011 SEG2506 - Chapître 1 5

Qualité du système

Hiver 2011 SEG2506 - Chapître 1 6

Le problème de communication

Hiver 2011 SEG2506 - Chapître 1 7

Points essentiels du contrôle de qualité

• Pour assurer que tous les liens de communication et toutes les étapes de transformation fonctionnent comme prévus:

– Le processus: Organisation du processus de développement en plusieurs étapes pendant lesquelles des documents spécifiques sont créés et certaines procédures de validation sont faites.

– Contenu technique: Le contenu des document variés, e.g. spécification des exigences, du système, plans de tests, etc.

Hiver 2011 SEG2506 - Chapître 1 8

Assurance de qualité

Hiver 2011 SEG2506 - Chapître 1 9

Les bénéfices du génie de systèmes (I)

• L’assurance de qualité peut être faite en étapes pendant tout le développement

• Les besoins des usagers et propriétaires sont mis au point

• La fonctionalité du système peut être validée tôt dans le cycle de développement

• Le nombre d’aspects à considérer dans chaque étape est réduit

• Le coût de la correction d’erreurs est réduit parce que les erreurs sont détectées plus tôt

Hiver 2011 SEG2506 - Chapître 1 10

Les bénéfices du génie de systèmes (II)• Les différentes descriptions correspondent à des savoir

d’experts différents• La notation (langage) peut être sélectionnée en

fonction du but de chaque description• Une description peut être modifié sans affecter les

autres descriptions (cela n’est pas complètement vrai, puisque on veut les garder consistantes entre elles – “traceability” )

• La conception fonctionnelle documente le système comme un tout, indépendemment de la technologie d’implantation pour les différentes parties du système

• Chaque étape fournit la fondation pour l’étape suivante

Hiver 2011 SEG2506 - Chapître 1 11

Quelques concepts

• Activité: la production de résultats

• Phase: période de temps pendant que des activités

spécifiques sont faites et des résultats sont obtenus

• “Baseline“ : résultat d’une phase, qui sert comme base pour le travail subséquent

• “ Milestone“ : transition de phase

Hiver 2011 SEG2506 - Chapître 1 12

Modèle d’activités

Hiver 2011 SEG2506 - Chapître 1 13

Possibilités pour l’automatisation de la construction de logiciel

• Des machine d’états et des diagrammes d’activités peuvent être utilisés comme prototype qui modélise les exigences fonctionnelles du système à construire – ou ils peuvent représenter une conception fonctionnelle du système.

• Après validation, le code d’implantation peut être généré automatiquement avec des outils CASE appropriés.

Hiver 2011 SEG2506 - Chapître 1 14

Vision de David Harel (i) en relation son travail sur les Live Sequence Charts (LSC)

Hiver 2011 SEG2506 - Chapître 1 15

Vision de David Harel (ii) le future … (maintenant et plus loin)

Hiver 2011 SEG2506 - Chapître 1 16

Chapître 1 (partie 1)

Revision de cours précédants

Sujet 2:L’analyse du domaine

(“problem domain analysis”)

Hiver 2011 SEG2506 - Chapître 1 17

Analyse du domaine C’est une phase important pendant l’analyse des exigences

• Le but de l’analyse du domaine est de comprendre le domaine du problème indépendamment d’un système particulier à développer

• On n’essaie pas de tracer la limite entre le système et son environnement

• On se concentre sur les concepts et la terminologie du domaine d’application avec une vue plus large que le système futur à développer

Hiver 2011 SEG2506 - Chapître 1 18

Les activités et résultats de l’analyse du domaine

• Un dictionnaire qui définit une terminologie commune et les concepts du domaine

• Une description du domaine d’un point de vue d’un modèle conceptuel

• Un diagramme d’héritage qui montre les relations entre les concepts

• Note: Plus tard on veut aussi un énoncé clair du but, des objectifs du nouveau système à construire et sa frontière par rapport aux autre entités dans le domaine. (Ce système à construire fait parti du domaine dans sa version future)

Hiver 2011 SEG2506 - Chapître 1 19

Documenter le modèle conceptuel du domaine

La modélisation par entités et relations (proposée à l’origine par Peter Chen en 1976)

– Entité: représente un type d’objets, définit les propriétés que toutes les instances de ce type auront.

– Relation: représente des liens entre instances de certains entités qui existent entre certains instances. Les types d’entités reliés s’appellent aussi rôles. L’ information sur la multiplicité indique combien d’instances “sur l’autre côté” peuvent être liées avec une instance “de ce côté”.

– Attribut: Une entité ou une relation peut avoir plusieurs attibuts. Chaque attribut est identifié par un nom et son type (qui est normalement un type de donnée simple, comme entier ou chaîne de caractères). Remarque: Un type d’entité n’est normalement pas utilisé comme type d’attribut, parce que dans une telle situation on utilise plutôt une relation entre l’entité donné et le type d’attribut.

• Notation suggérée: diagramme de Classe UML

Hiver 2011 SEG2506 - Chapître 1 20

La spécification des exigences = Conception externe

• La spécification des exigences est “L’invention et la définition du comportement du nouveau système (dans la nouvelle version future du domaine) tel qu’il produira les effets souhaités dans le domaine”

• Pendant l’analyse des exigences, on trouve les propriétés du domain actuel, et aussi les exigences qui devraient être réalisées dans la version future du domaine. Nous faisons l’hypothèse que la version future du domaine inclut un nouveau système à construire, tandis que d’autres aspects du domaine pourraient aussi changer dans la version future.

• La détermination de cette version future du domaine, incluant le nouveau système à construire, est un cas typique d’un processus de conception. On l’appelle Conception externe, parce que le nouveau système est considéré en “black-box” à l’intérieur de la version future du domaine – qui est considérée en “white-box”; et il s’agit de concevoir cette version future du domaine.

• Note: Pendant ce processus, la limite entre le système à construire et les autres entités dans le domaine est établie.