Objectifs du cours. Génie logiciel. Software engineering. Pourquoi un processus?

Dimension: px

Commencer à balayer dès la page:

Download "Objectifs du cours. Génie logiciel. Software engineering. Pourquoi un processus?"

Josselin Gauvin
il y a 8 ans
Total affichages :

1 Objectifs du cours Génie logiciel Philippe Dugerdil. Comprendre la nécessité d un processus de développement et son rôle. 2. Comprendre et mettre en œuvre les trois premières phases du Processus Unifié (Inception, Elaboration, Construction) Software engineering «The disciplined application of engineering, scientific and mathematical ti principles i methods and tools to the economical production of quality software» [Watts S. Humphrey Managing the Software Process, Addison-Wesley, 989] Pourquoi un processus? "Software Engineering Process: the total set of software engineering activities needed to transform a user's s requirement into software Watts S. Humphrey - Managing the Software Process, Addison-Wesley, 989 "The most significant improvements in quality and productivity come from improvements to the process of systems development, this can occur only when everyone is following the same process in a standardized fashion. Edward Yourdon - Decline and Fall of the American Programmer, Yourdon Press, Prentice Hall, 999 High quality reliable systems are produced by high-quality architecting, engineering, design and manufacture, not by inspection, tests and rework. Rechtin E.- System Architecting-Creating & Building Complex Systems, Prentice Hall 99.

.0.2008 2008 Software engineering «The disciplined application of engineering, scientific and mathematical ti principles i methods and tools to the economical production of quality software» [Watts S.

2 La pensée du «Gourou» What is the most important aspect of a modelling and design methodology?. Formal consistency? 2. Reusability? 3. Efficiency i? 4. Faithfulness to object oriented principles? No. None of this matters a bit if you don't solve the right problem. James Rumbaugh Specification (requirements) «In fact, we often do not really understand what we want or how to build it until we have finished» [Humphrey W.S. Managing the Software Process. Addison-Wesley, 990] «(we must) treat software development as a learning process» [Humphrey W.S. Managing the Software Process. Addison-Wesley, 990] Première difficulté: résoudre le bon problème.. en prenant en compte le contexte Utilisateur Informaticien

James Rumbaugh Specification (requirements) «In fact, we often do not really understand what we want or how to build it until we have finished» [Humphrey W.S. Managing the Software Process.

3 qu on a parfois tendance à occulter. cessor3 cessor5 Elaborer des modèles pour communiquer et construire cessor3 cessor5 NewP ro cessor6 cessor4 base cessor7 cessor cessor2 cessor8 ce ce2 cessor3 cessor5 cessor6 cessor7 cessor2 ce cessor3 cessor6 NewP ro cessor4 base cessor cessor8 ce2 cessor5 NewP ro cessor6 NewP ro cessor4 cessor7 base cessor4 cessor cessor7 ce cessor2 base cessor8 cessor ce2 cessor2 ce cessor8 ce2 c est vrai aussi pour le logiciel. D abord: dialoguer avec le mandant Réservation chambre Ecran de check in Validati onvi ew OccupationVie w Suppression réservation << co nt rol >> CheckIn Responsable des réservations Chec k-in Changement de chambre Horloge de l'hôtel Lecteur de carte magnétique displayva lid ati on () GestionnaireOccupation getoccupationfomnameanddate(string) $ Singleton Horloge nom,date current Occupation datedebut() datefin() personne() chambre() di splay() Personne nom() adresse() Chambre numero() Prolongation séjour Directeur Caissier Règlement de la note Centrale de carte de crédit Affichage Dialogue de demande insertion carte display(model) Sejour Reservation Interface lecteur cartes enregistre(reservation) Réservation chambre Suppression réservation Check-in Horloge de l'hôtel client commandes Responsable des réservations Changement de chambre Lecteur de carte magnétique Prolongation séjour Caissier Règlement de la not e Centrale de carte de crédit Utilitaires Communication Directeur

cessor3 cessor6 NewP ro cessor4 base cessor cessor8 ce2 cessor5 NewP ro cessor6 NewP ro cessor4 cessor7 base cessor4 cessor cessor7 ce cessor2 base cessor8 cessor ce2 cessor2 ce cessor8 ce2 c est

4 Validati onvi ew OccupationVie Ecran de check in w << co nt rol>> CheckIn displayva lid ati on () current Personne Horloge Occupation nom() GestionnaireOccupation eoccupat o adresse() nom,date datedebut() getoccupationfomnameanddate(string) datefin() personne() $ chambre() Chambre Singleton di splay() numero() Dialogue de demande insertion carte display(model) Sejour Reservation Interface lecteur cartes enregistre(reservation) Responsable des réservations Directeur Caissier Réservation chambre Suppression réservation Chec k-in Changement de chambre Prolongation séjour Règlement de la note Horloge de l'hôtel Lecteur de carte magnétique Centrale de carte de crédit ValidationVi ew OccupationVie Ecran de check in w << co nt rol>> CheckIn displayva lid ati on () current Personne Horloge Occupation nom() GestionnaireOccupation adresse() nom,date datedebut() getoccupationfomnameanddate(string) datefin() person ne () $ chambre() Chambre Singleton numero() Dialogue de demande insertion carte display(model) client Utilitaires Sejour Affichage base Reservation Interface lecteur cartes enregistre(reservation) commandes Communication Ecran de check in << co nt rol >> CheckIn displayva lidati on() Dialogue de demande insertion carte display(model) GestionnaireOccupation Validati onvi ew getoccupationfomnameanddate(string) $ Singleton Horloge nom,date current Sejour OccupationVie w datedebut() datefin() personne() chambre () di splay() Occupation Reservation Personne nom() adresse() Chambre numero() Interface lecteur cartes enregistre(reservation) puis avec le développeur et finalement la mise en œuvre. Affichage Réservation chambre Suppression réservation client commandes Check-in Horloge de l'hôtel Utilitaires Communication Responsable des réservations Changement de chambre Lecteur de carte magnétique Prolongation séjour Caissier Règlement de la note Centrale de carte de crédit Affichage Directeur client Utilitaires commandes Communication base Des modèles élaborés dans un processus formalisé Que faire? Comment faire? Faire dont le suivi peut être certifié. ISO 900 Binaire (obtention / échec) CMM (SEI / CMU) 5 niveaux (initial, reproductible, défini, géré, optimisé) Livrer D après: RUP2000, Rational Software Corp, 2000

lecteur cartes enregistre(reservation) Responsable des réservations Directeur Caissier Réservation chambre Suppression réservation Chec k-in Changement de chambre Prolongation séjour Règlement de la

5 CMM quelques repère en France Développer par itération Les chiffres du CMM en France ere SSII certifiée CMMI 3 en France : Axlog, du groupe Aztek. Moins d'une dizaine de SSII ont obtenu ce niveau de certification. 3 ans est la durée minimale pour passer du niveau au niveau sociétés indiennes étaient déjà certifiées CMM 5 à la mi IBM Global Services est la seule SSII certifiée CMMI 5 dans l'hexagone [Olivier Discazeaux, 0 Informatique (n 853), 03/05/2006 ] Incréments des minis projets Phases, disciplines et activités Workflow Copyright Rational Software Corporation

89 sociétés indiennes étaient déjà certifiées CMM 5 à la mi- 2005.

6 Le logiciel est une lutte continue «Lois de lehman» Loi du changement continu: Un programme utilisé tilié en environnement réel él dit doit être continûment adapté ou devenir progressivement moins utile dans cet environnement. Loi de croissance de la complexité: A mesure qu un programme évolue, sa structure a tendance a devenir plus complexe. Des ressources supplémentaires doivent donc être allouées pour maintenir i sa structure t et la simplifier. Coût de la maintenance sur le cycle de vie du logiciel Year Proportion of Definition Reference software maintenance costs 2000 >90% Software cost devoted d to system maintenance & Erlikh (2000) evolution / total software costs % Software maintenance / information system budget (in Fortune 000 companies) 990 >90% Software cost devoted to system maintenance & evolution / total software costs % Software maintenance / total management information systems (MIS) operating budgets % Software maintenance / total management information systems (MIS) operating budgets % Effort spent on software maintenance / total available software engineering effort. 98 >50% Staff time spent on maintenance / total time (in 487 organizations) Eastwood (993) Moad (990) Huff (990) Port (988) McKee (984) Lientz & Swanson (98) % Maintenance costs / total software costs Zelkowitz et al. (979) Source: Jussi Koskinen - Software Maintenance Costs. Information Technology Research Institute, University of Jyväskylä, Finland. Updated: Sept. 28, 2004 Résumé UP, phases, milestones Maintenance : ~60-80% du coût du logiciel Compréhension: ~40-60% de la maintenance

Des ressources supplémentaires doivent donc être allouées pour maintenir i sa structure t et la simplifier.

7 Caractéristiques de RUP Specifications Processus basé sur 6 «best practices». Développer le logiciel itérativement. 2. Gérer les spécifications. 3. Utiliser des architectures basées composants. 4. Mdéli Modéliser le logiciel iil visuellement. 5. Vérifier la qualité du logiciel en permanence. 6. Contrôler les modifications du logiciel (versions). Discipline: spécification Storyboards Doc de vision Glossaire Acteurs, UC model «Règles gestion» Use-cases Spec. suppl. Copyright Rational Software Corporation

Vérifier la qualité du logiciel en permanence. 6. Contrôler les modifications du logiciel (versions).

8 Le modèle des besoins Qu est-ce qu un besoin? Comment le représenter? Un peu de vocabulaire Besoin (need) : problème business, personnel ou opérationnel justifiant la mise en œuvre d une solution informatique. Caractéristique de la solution (feature) : service que le système va offrir pour répondre au besoin. Spécification informatique (requirement) : spécification du système permettant de résoudre le problème en offrant les services énumérés. Activité: analyser le problème Glossaire Copyright Rational Software Corporation

informatique. Caractéristique de la solution (feature) : service que le système va offrir pour répondre au besoin.

9 Document de Vision Le document de vision Définition des termes et documents de référence Premier document d analyse UP Trace les grandes lignes du projet (la vision!) Accompagné du modèle métier, il permet de comprendre le contexte et motivations du projet. Position du projet Lien avec le business Problème à résoudre Produit envisagé Produits concurrents Utilisateurs et intervenants Segments de marché Intervenants et responsabilités Utilisateurs, nombre et responsabilités Besoins essentiels avec priorité Vision II Produit Environnement technique. composant /stand alone Résumé des caractéristiques du produit et lien avec les besoins des utilisateurs Contraintes à la réalisation Marché (coût, prix, politique de licence, installation) Caractéristiques du produit Contraintes non fonctionnelles Etude du template du document de Vision

Position du projet Lien avec le business Problème à résoudre Produit envisagé Produits concurrents Utilisateurs et intervenants Segments de marché Intervenants et responsabilités Utilisateurs, nombre

Documents pareils

Editing and managing Systems engineering processes at Snecma

Editing and managing Systems engineering processes at Snecma Atego workshop 2014-04-03 Ce document et les informations qu il contient sont la propriété de Ils ne doivent pas être copiés ni communiqués