Ingegneria del Software (e Prova Finale)
annuncio pubblicitario
IngegneriadelSoftware (eProvaFinale) LucianoBaresi [email protected] Organizzazionedeicorsi • Ingegneriadelsoftware(7crediti) – Lezioni:42ore – Esercitazioni:28ore • Provafinale(3crediti) – Esercitazioni:16ore – Laboratorio:28 ore Chisiamo • Titolaredelcorso – LucianoBaresi • Esercitazioni – AlessandroCampi • Laboratorio – AlessandroCampi Orario • Martedì – 14:15– 18:15 • Giovedì – 9:15– 13:15 • Martedì (laboratorio) – 9:15– 13:15 Marzo 7 Lez M Introduzione/Java 2 9 G Java 4 14 M Java 4 16 G EserJava 21 M EserJava 23 G ThreadseSockets 28 M EserJava/Threads 30 G RMI 4 M EserRMI 6 G UMLeprogettazioneOO 4 M ProgettazioneOOedesignpattern 4 13 G Esercitazioneprogettazione 18 M 20 G 25 M 27 G Eser Lab 4 4 4 4 4 Aprile 4 4 Astrazioni(introeprocedurali) 4 Maggio 2 M 4 G 9 M JavaFX 11 G AstrazioniADT 16 M EserUML/progettazione/pattern 18 G Astrazioniereditarietà 23 M EserastrazionifunzionalieADT 25 G Lezionesospesa 30 M EserJavadistribuito 1 G Lezionesospesa 6 M Eserastrazioniereditarietàetemid'esame 8 G Java8 13 M Test Eclipse/JavaeVersioneconfmanagement 4 4 4 4 Progetto 4 4 Progetto 4 4 4 4 4 4 4 Progetto 4 Giugno 15 G 20 M Progetto 4 Progetto Valutazioneprogetti 4 42 44 28 Programma • Programmazioneorientataaglioggetti(Java) • Programmazioneconcorrente,diretee distribuita • Programmazionedelleinterfacceutente(JavaFX) • Progettazioneorientataaglioggetti – Unified Modeling Language – Designpattern • Specificadimetodieclassi • Testfunzionaleestrutturale Materialedidattico • Nonesisteunlibroditestounico • http://home.deib.polimi.it/baresi/is.htm Obiettivi • Progettazioneeprogrammazioneadoggetti – Java/RMI/JavaFX – UML • Specificarigorosa(percontratti) • Elementiperiltestsistematicodeiprogrammi Iniziamo? IngegneriadelSoftware • Settoredell'informaticachestudiasistemi – complessiedigrandidimensioni – nati dallavorodigruppo • Questisistemi – esistonoindiverseversioni – hannounaduratadianni – sonosoggettiafrequentimodifiche Possibilidefinizioni • Approcciosistematicoallosviluppo,allamessain operaeallamanutenzionedelsoftware • Metodi tecniciemanagerialiperprevederee teneresottocontrolloicostipertuttalavita ("lifecycle")deiprodottisoftware • Cometutteleingegnerie: – Fornisceunaguidaperapplicarelaconoscenza scientificaallosviluppodisoluzioni(software)"costeffective"perrisolvereproblemipraticiabeneficio dell'uomo Processoeprodotto • Processo – Come avvienelosviluppoindustrialedelsoftware • Prodotto – Checosavieneprodotto? Studiare i metodi dausare perché il processo porti allo sviluppo diprodotti diqualità Ingegneria • Progettonormale/standard – Soluzioneaunproblemanotoericorrente – Riusodisoluzioninote – Innovazionelimitata • tipicodidisciplinemature • Progettoinnovativo – Soluzioniradicalmentenuoveaprobleminonnoti • Occorresaperdistingueretraidue Confrontoconingegneriatradizionale • (Troppo)spessovienetrattatacome“progetto innovativo” • (Troppo)spessovienepraticatainmodopoco sistematico(ingegneristico/industriale) Differenze (rispettoaingegnerietradizionali) • Prevaleilprogettodiroutine • Progettodiestremodettagliocheproducele specificheperlarealizzazione • Processodiproduzioneseparato • Progettialternativiconvalidatiattraversomodelli • Dopoilprogetto,pochimarginidicambiamento • Processistandardperprogettoeproduzione Ingegneriadelsoftware(1) • L’ingegneriacivilehaallespalle3000anni – Unpatrimoniodiconoscenze • Ciòèveroperquasitutteleingegnerie • L’ingegneriadelsoftwarehasolo50anni Ingegneriadelsoftware(2) • Congelarelespecifichediprodottoedi progettoèspessononrealistico • Cambiamentiedevoluzionespessoinevitabili – poichèilsoftwareèilcuoredeiprocessisocialie dibusiness – Questicontinuanoadevolvere Ilsoftwareoggi • Ilsoftwareèparteessenzialedimoltiprodottidi largoconsumo – Daltelefoninoallalavatrice,dall’automobilealforno • Spessoilsoftwarenonèilprodotto,maèuna partedelprodotto – Deveessereingegnerizzatoconilresto dell’applicazione • Ilmeccanismodellepatchnonfunzionaintutti questicasi – ComefaccioadattaccarelamacchinaadInternet Complessità,criticitàedimensione • Fannolaveradifferenza – Richiedonounapprocciosistematico (ingegneristico)perpoterottenerelanecessaria qualitàcontrollandocostietempi • SecondoF.Brooks(TheMythicalManMonth) – "programmarepersestesso"rispettoa "programmareperaltri"->costoalquadrato – Aggiungerepersoneaunprogettoinritardolo ritardaulteriormente CHAOSreport(I) OVERRUNS AND FEATURES Time and cost overruns, plus percentage of features delivered from CHAOS research for the years 2004 to 2012. 100 80 60 40 Features 20 Cost Time 0 2004 2006 2008 2010 2012 TIME 84% 72% 79% 71% 74% COST 56% 47% 54% 46% 59% FEATURES 64% 68% 67% 74% 69% Determining the relationship of project overruns to features delivered is an analytical process. An analyst reviews each challenged project. This year’s figures show a slight increase in both cost and time overruns. Cost overruns increased from 56% in 2004 to 59% in 2012. Time overruns also Progettazionevs.Programmazione • Programmatore – Sviluppa unprogrammacompleto – Partendo daspecifichefornitedaaltri – Lavora individualmente • Ingegnere delsoftware – Analizza problemiedominiapplicativi – Coglie irequisitiesviluppaspecifiche – Progetta componenti,potenzialmenteriusabili – Lavora inungruppo Progettazione • Scomposizionediunsistemainmoduli – scomporreunproblemainsotto-problemiche possanoessererisoltiindipendentemente • Qualiobiettividellascomposizione? – governarelacomplessità • divideetimpera – rendereefficienteilprocesso • sviluppoindipendentedelleparti • Riduzionediconflitti/incomprensionifraglisviluppatori
