Hiver 2011SEG Chapître 11 Chapître 1 (partie 1) Revision de cours précédants Sujet 1: Le processus de développement de logiciel

Hiver 2011SEG Chapître 12 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 derreurs: –Planifier une fonctionnalité en désaccord avec le but du système –Définir une fonctionnalité inconsistante à linterne –Implanter la fonctionnalité différente que planifié

Hiver 2011SEG Chapître 13 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 leffort 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 2011SEG Chapître 14 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 dune bonne communication (précise et sans ambiguïté) pendant le développement du système (voir diagramme).

Hiver 2011SEG Chapître 15 Qualité du système

Hiver 2011SEG Chapître 16 Le problème de communication

Hiver 2011SEG Chapître 17 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 2011SEG Chapître 18 Assurance de qualité

Hiver 2011SEG Chapître 19 Les bénéfices du génie de systèmes (I) Lassurance 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 daspects à considérer dans chaque étape est réduit Le coût de la correction derreurs est réduit parce que les erreurs sont détectées plus tôt

Hiver 2011SEG Chapître 110 Les bénéfices du génie de systèmes (II) Les différentes descriptions correspondent à des savoir dexperts 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 nest 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 dimplantation pour les différentes parties du système Chaque étape fournit la fondation pour létape suivante

Hiver 2011SEG Chapître 111 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 dune phase, qui sert comme base pour le travail subséquent Milestone : transition de phase

Hiver 2011SEG Chapître 112 Modèle dactivités

Hiver 2011SEG Chapître 113 Possibilités pour lautomatisation de la construction de logiciel Des machine détats et des diagrammes dactivité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 dimplantation peut être généré automatiquement avec des outils CASE appropriés.

Hiver 2011SEG Chapître 114 Vision de David Harel (i) en relation son travail sur les Live Sequence Charts (LSC)

Hiver 2011SEG Chapître 115 Vision de David Harel (ii) le future … (maintenant et plus loin)

Hiver 2011SEG Chapître 116 Chapître 1 (partie 1) Revision de cours précédants Sujet 2: Lanalyse du domaine (problem domain analysis)

Hiver 2011SEG Chapître 117 Analyse du domaine Cest une phase important pendant lanalyse des exigences Le but de lanalyse du domaine est de comprendre le domaine du problème indépendamment dun système particulier à développer On nessaie pas de tracer la limite entre le système et son environnement On se concentre sur les concepts et la terminologie du domaine dapplication avec une vue plus large que le système futur à développer

Hiver 2011SEG Chapître 118 Les activités et résultats de lanalyse du domaine Un dictionnaire qui définit une terminologie commune et les concepts du domaine Une description du domaine dun point de vue dun modèle conceptuel Un diagramme dhé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 2011SEG Chapître 119 Documenter le modèle conceptuel du domaine La modélisation par entités et relations (proposée à lorigine par Peter Chen en 1976) –Entité: représente un type dobjets, 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 dentités reliés sappellent aussi rôles. L information sur la multiplicité indique combien dinstances sur lautre 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 dentité nest normalement pas utilisé comme type dattribut, parce que dans une telle situation on utilise plutôt une relation entre lentité donné et le type dattribut. Notation suggérée: diagramme de Classe UML

Hiver 2011SEG Chapître 120 La spécification des exigences = Conception externe La spécification des exigences est Linvention et la définition du comportement du nouveau système (dans la nouvelle version future du domaine) tel quil produira les effets souhaités dans le domaine Pendant lanalyse 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 lhypothèse que la version future du domaine inclut un nouveau système à construire, tandis que dautres 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 dun processus de conception. On lappelle Conception externe, parce que le nouveau système est considéré en black-box à lintérieur de la version future du domaine – qui est considérée en white-box; et il sagit 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.