Appunti di Ingegneria del software - .Agile è una metodologia di sviluppo del software, un...

download Appunti di Ingegneria del software - .Agile è una metodologia di sviluppo del software, un framework.

of 25

  • date post

    28-Sep-2018
  • Category

    Documents

  • view

    213
  • download

    0

Embed Size (px)

Transcript of Appunti di Ingegneria del software - .Agile è una metodologia di sviluppo del software, un...

  • Ingegneria del softwareversione 1.0.5

    :::::::::::Appunti

    19 luglio 2006

    Indice

    1 Ciclo di vita del software 31.1 Processo di sviluppo del soft-

    ware . . . . . . . . . . . . . . 41.2 Modelli . . . . . . . . . . . . 41.3 Agile . . . . . . . . . . . . . . 5

    1.3.1 Dierenze con altrimodelli . . . . . . . . 5

    1.3.2 Quando usarlo . . . . 51.4 Iterativo - Incrementale . . . 51.5 RAD . . . . . . . . . . . . . . 6

    1.5.1 Vantaggi Svantaggi . . 61.6 Extreme Programming . . . . 6

    1.6.1 Planning Game . . . . 71.6.2 Small Relesases . . . . 71.6.3 Customers on-Site . . 71.6.4 Test First . . . . . . . 71.6.5 Refactoring . . . . . . 81.6.6 Simplicity . . . . . . . 81.6.7 System Metaphor . . . 81.6.8 Pair Programming . . 81.6.9 Collective Code Ow-

    nership . . . . . . . . 81.6.10 Continous Integration 91.6.11 Standards . . . . . . . 91.6.12 Overtime: 40 hour week 91.6.13 JUnit . . . . . . . . . 9

    1.7 RUP . . . . . . . . . . . . . . 111.7.1 RUP best practices . . 111.7.2 Ciclo di vita del Pro-

    getto . . . . . . . . . . 111.7.3 Il modello a Cascata -

    WaterFall . . . . . . . 121.7.4 Il modello a Spirale . 12

    1.7.5 Il modello a Release . 13

    2 UXF 13

    3 Metriche codice sorgente 143.1 LOC . . . . . . . . . . . . . . 14

    3.2 eLOC . . . . . . . . . . . . . 14

    3.3 lLOC . . . . . . . . . . . . . . 14

    3.4 DLOC . . . . . . . . . . . . . 14

    3.5 SLOC . . . . . . . . . . . . . 14

    3.5.1 Vantaggi . . . . . . . . 15

    3.5.2 Svantaggi . . . . . . . 15

    4 UMM 15

    5 XMI 15

    6 COTS 16

    7 SCM 167.1 Goal . . . . . . . . . . . . . . 16

    8 FPA 17

    9 COCOMO 189.1 Basic COCOMO . . . . . . . 18

    10 COCOMO II 19

    11 CORBA 20

    12 DFD 20

    13 Linguaggio Z 2013.1 Esempio - Denizione sistema 21

    13.2 Esempio - Add . . . . . . . . 21

  • 2 Indice

    14 Diagrammi UML 22

    14.1 Diagramma casi d'uso . . . . 22

    14.2 Diagramma delle classi . . . . 22

    14.3 Diagramma delle sequenze . . 23

    14.4 Diagramma delle collabora-zioni . . . . . . . . . . . . . . 23

    14.5 Diagramma di stato . . . . . 2314.6 Diagramma delle attivit . . 2314.7 Diagramma dei componenti . 2314.8 Diagramma di distribuzione

    dei componenti (deployment) 24

    Bibliograa 25

  • 1 Ciclo di vita del software 3

    1 Ciclo di vita del software

    L'espressione ciclo di vita del software si riferisce al modo in cui una metodo-logia di sviluppo o un modello di processo scompongono l'attivit di realizza-zione di prodotti software in sottoattivit fra loro coordinate, il cui risultatonale il prodotto stesso e tutta la documentazione a esso associato[1].Esistono varie fasi:

    1. Analisi: ovvero l'indagine preliminare sul contesto in cui il prodottosoftware deve inserirsi, sulle caratteristiche che deve esibire, ed even-tualmente su costi e aspetti logistici della sua realizzazione; questa fasepu essere scomposta in sottoattivit quali:

    (a) analisi di fattibilit,

    (b) analisi e modellazione del dominio applicativo,

    (c) analisi dei requisiti.

    2. Progetto: in cui si deniscono le linee essenziali della struttura delsistema da realizzare, in funzione dei requisiti evidenziati dall'analisie dal documento nale da essa creato. Anche questa fase pu esserescomposta in sottoattivit:

    (a) progetto architetturale,

    (b) al progetto dettagliato.

    In questa fase verr sviluppando un documento che permetter di avereuna denizione della struttura di massima (architettura di alto livello)e una denizione delle caratteristiche dei singoli componenti (moduli)

    3. Implementazione

    4. Testing

    (a) testing dei singoli moduli,

    (b) testing del sistema integrato,

    (c) test funzionali,

    (d) test di performance,

    (e) test di accettazione,

    (f) test d'installazione.

    5. Manutenzione

  • 4 1 Ciclo di vita del software

    1.1 Processo di sviluppo del software

    L'UML (Unied Modelling Language), ad esempio, un linguaggio di mo-dellazione, utilizzato dai processi per realizzare, organizzare, documentare iprodotti realizzati dalle fasi di cui il processo si compone. Coloro che, indivi-dualmente o in gruppo, lavorano allo sviluppo o alla modica di un software,adottano necessariamente un certo approccio nel modo di relazionarsi coni propri clienti/utenti, nell'organizzare il proprio lavoro, nella scelta delletecniche da utilizzare. Adottano un processo [1].

    Il ciclo di sviluppo del software, nella maggior parte dei casi, iterativo,e ogni iterazione produce una sua release. Elenchiamo di seguito le fasiprincipali che possono far parte di ogni singola iterazione:

    1. Specica dei requisiti: ci che viene richiesto dal committente

    2. Analisi e Design dove per analisi si intende lo studio di cosa deve fare ilsistema (punto di vista logico) e per design lo studio di come il sistemadeve venire implementato (punto di vista tecnico). Negli ultimi anni,la distinzione tradizionale tra analisi e design entrata in crisi.

    3. Implementazione

    4. Integrazione e test

    1.2 Modelli

    Esistono molti modelli per lo sviluppo del software:

    iterativo (1970 - 1992),

    Waterfall (a cascata) (1970),

    RAD (1980 - 1991),

    spirale (1985),

    RUP (1998),

    Extreme Programming (XP) (1999).

    Agile (2001),

  • 1 Ciclo di vita del software 5

    1.3 Agile

    Agile una metodologia di sviluppo del software, un framework.Ci sono pi tipi di agile software per sviluppare questo metodo, questi pos-sono essere trovati nell'organizzazione no-prot The Agile Alliance.Questo metodo tenta di minimizzare i rischi dello sviluppo con piccole time-boxes, chiamate iterazioni, da una a quattro settimane.Ogni iterazione include delle fasi: planning, requirements analysis, design,coding, testing e documentation.Mentre una iterazione non garantisce il rilascio di un prodotto, l'agile soft-ware project, si propone di riuscire a rilasciare un nuovo software ad ogniiterazione. Alla ne di ogni iterazione, il tema ssa le priorit del progetto.

    1.3.1 Dierenze con altri modelli

    Adaptive....................................Predictive

    Adaptive methods: si concentra sull'adattarsi velocemente ai cam-biamenti.

    Predictive methods: si concentra sulla pianicazione dettagliata efutura del progetto

    1.3.2 Quando usarlo

    Pi di 20 sviluppatori,

    distanza tra glil sviluppatori,

    mission- and life-critical eorts,

    command-and-control company cultures.

    1.4 Iterativo - Incrementale

    Il modello iterativo, e incrementale, risponde alle debolezze dei modelli wa-tefall. I due modelli di sviluppo iterativo pi conosciuti sono RUP (RationalUnied Process), e DSDM (Dynamic Systems Development Method).Questo modello una parte essenziale dell'XP (Extreme Programming) etutti gli altri agile software frameworks.

  • 6 1 Ciclo di vita del software

    1.5 RAD

    (Rapid Application Development) RAD nato come risposta al metodologianon-agile, come il modello waterfall.Il problema con i precedenti modelli era quello che i requisiti cambiasseroprima della conclusione del progetto, con il risultato di creare sistemi nonutilizzabili.

    1.5.1 Vantaggi Svantaggi

    accresce la velocit e qualit di sviluppoQuesta velocit dovuta all'uso di tool quali CASE1

    Per qualit nel modello RAD si intende il grado con il quale l'appli-cazione nita si riscontra con le aspettative del cliente, ed i costi dimanutenzione bassi.

    Come svantaggi, riduce la scalabilit e le features.La scalabilit ridotta perch questo modello parte da un prototipo esi evolve no alla applicazione nita; mentre riduce le features questo dovuto al time boxing, le features vengono inserite tardi nelle versioninali della release.

    1.6 Extreme Programming

    L'extreme programming XP, un modo di programmare che segue deter-minate regole, per cercare di ottimizzare il pi possibile lavoro fatto daiprogrammatori [2]. Alcune di queste regole sono di seguito riportate:

    1. Planning Game

    2. Small Releases (Piccole release)

    3. Customers on-Site (Cliente sulposto)

    4. Test First

    5. Refactorig

    6. Simplicity

    7. System Metaphor

    8. Pair Programming

    9. Collective Code Ownership

    10. Continous Integration

    11. Code Standards

    12. Overtime: 40 hour week

    13. ...1L'obiettivo di questo tool quello di catturare i requisiti e descriverli come codice nel

    modo pi veloce possibile.

  • 1 Ciclo di vita del software 7

    1.6.1 Planning Game

    Come Pianicare:

    Creare delle priorit (con il cliente)

    Stimare la dicolt dei lavori (Lo sviluppatore)

    Lavorare in task paralleli, si pi veloci (Lo sviluppatore)

    Pianicare insieme i lavori ed i vari task all'inizio (Sviluppatore-Cliente)

    1.6.2 Small Relesases

    Signica piccole release frequenti, in genere prima dell'XP, si faceva il soft-ware per intero e poi si dava al committente validato; mentre ora si cerca didare subito qualcosa al cliente, in modo che capisca subito se il software corretto secondo le sue speciche; questo evita di fare lavoro inutile.

    In genere per il cliente viene sviluppato subito il 10% del programma inmodo tale che sia veloce il riscontro in caso di problemi.Questa tecnica, evita la nascita e la morte poi di determinati software, con laperdita quindi di tempo e denaro, inoltre fa subito vedere se ci sono errori2

    o difetti3 nei software prodotti.

    1.6.3 Customers on-Site

    Il committente deve essere tenuto sempre in stretto contatto con gli svilup-patori. In genere succede che dopo aver ottenuto l'ordine di progettare unsoftware, il programmatore ed il cliente non si sentono quasi pi no a soft-ware terminato: questo non deve succedere.

    Con