Anteprima
Vedrai una selezione di 20 pagine su 119
Appunti di Ingegneria del Software Pag. 1 Appunti di Ingegneria del Software Pag. 2
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 6
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 11
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 16
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 21
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 26
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 31
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 36
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 41
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 46
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 51
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 56
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 61
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 66
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 71
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 76
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 81
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 86
Anteprima di 20 pagg. su 119.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del Software Pag. 91
1 su 119
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

BCWP/ BACcome:

N.B: Eventuali attività iniziate ma non completate non vengono considerate nella somma (es. un'attività di 6 unità che è stata fatta a metà non viene contata come un'attività di 3 unità). Banalmente perché non si sa realmente quanto dell'attività è stata completata.

Esempio:

Cost Variance: Viene intesa come la differenza tra i costi previsti dalle attività fatte fino a quel momento e i costi reali delle stesse attività: BCWP - ACWP

Schedule Variance: Fa capire in maniera efficace quelli che sono i tempi effettivi del progetto. Si misura come: BCWP - BCWS

Un errore in questi valori calcolati non implicano per forza un uso eccessivo di risorse, quindi maggiori costi, o ritardi nei tempi. Le stime rimangono comunque tali e soggette ad errore.

Software Pricing: Il costo di un progetto software non va confuso con quello che è il suo prezzo. Il costo è una stima per chi.

mercato.● Competizione: se ci sono molte aziende che offrono servizi simili, potrebbe esserci unapressione per abbassare i prezzi al fine di rimanere competitivi.● Valore percepito dal cliente: se il cliente percepisce un alto valore nel software, potrebbeessere disposto a pagare un prezzo più elevato.Nonostante questi fattori, è importante che il prezzo richiesto copra i costi di sviluppo delsoftware e generi un margine di profitto per l'azienda.mercato(in ottica futura per avere nuovi contratti e maggiore esperienza)
  • Volatilità dei requisiti: un progetto con requisiti poco chiari e con la possibilità di aggiungerne altri, l'azienda che prende il progetto potrebbe chiedere un prezzo basso per i requisiti iniziali e alzare il prezzo per quelli successivi.

Strategie di Pricing

Ci sono una serie di motivazioni per cui si può scegliere una strategia piuttosto che un'altra. Si effettuano underpricing oppure overpricing.

Costi nascosti

Le aziende stimano i costi in base ai mesi uomo che ci vorranno per il progetto: una stima del genere crea una perdita, in quanto le aziende hanno dei costi che sono oltre quello del progetto (affitto, bollette, rete internet etc...). La quota delle spese è calcolata secondo un fattore di proporzionalità tra il costo del personale e i costi legati all'azienda. (es. costo del personale 100 e costi dell'azienda 30, allora il fattore di

La proporzionalità è del 30%. Su ogni progetto aggiungo il 30% del costo totale del progetto.

Pricing to win è una strategia con la quale un'azienda vuole a tutti i costi ottenere un contratto per un progetto (per problemi finanziari, per esempio). L'azienda fissa il prezzo in base a quanto il cliente è disposto a pagare. Stabilisco il prezzo ignorando il costo che porterà all'azienda.

Lezione 8 11/10/21

(La lezione 6 è stata fatta esercitazione, mentre la lezione 7 è stata utilizzata per la discussione dell'esercitazione)

Agile Methodologies

Si tratta di un processo di produzione del software che si discosta da quelli presentati in precedenza. Infatti, questo modello di processo non segue quelli definiti tradizionali. È stato proposto alla fine degli anni '90 come alternativa ai processi già esistenti, proponendo un approccio in cui si dava meno enfasi alla capacità di prevedere e pianificare.

Anticipo lo svolgimento del progetto, e più importanza ai feedback costanti e rapidi sull’andamento del progetto. Questi modelli, di cui Scrum fa parte, sono meno predittivi e più reattivi.

Nel 2001, i proponenti dei metodi hanno coniato un termine per racchiudere le caratteristiche fondamentali e simili di questi processi, ovvero Agile.

Scrum

Scrum è una delle metodologie Agili più usate, forse la più usata. Non è l’acronimo di un qualcosa, non è una sigla, ma un termine preso in prestito dal Rugby che significa “mischia”. Questo enfatizza il fatto che in questa metodologia, i membri del team devono avere una certa coesione e lavoro di squadra.

Scrum è un processo Agile che pone grande attenzione sul consegnare il massimo “valore” per il cliente nel minimo tempo possibile. Permette di effettuare controlli rapidi e continui sul lavoro effettuato. Il cliente può fin da subito mettere mano al software.

anche se noncompleto, per poter fornire feedback e collaborare attivamente con il team di sviluppo. Questo è molto simile all'approccio dei metodi iterativi. Difatti Scrum rientra nel metodo iterativi e, un'iterazione ha una breve durata, settimane o al massimo un mese. Il cliente determina le priorità ed è il team di sviluppo che decide come raggiungere gli obiettivi prefissati dal cliente. Periodicamente c'è una release, alla fine dell'iterazione, che mostra software effettivamente funzionante, non modelli o diagrammi. Qui il cliente decide se andare avanti con il progetto o fermarsi. Le strategie di overpricing o underpricing non possono essere attuate con questa metodologia, in quanto il prezzo non viene deciso a priori, essendoci la possibilità che il cliente termini il progetto prima della sua effettiva realizzazione.

Storia di Scrum

1995: La storia di Scrum inizia con due ingegneri del software, ovvero Jeff Sutherland e Ken Schwaber.

Schwaber● 1996: Viene presentato alla conferenza OOPSLA● 2001: Pubblicazione del primo libro che presenta il processoAd oggi è probabilmente il processo di produzione Agile più utilizzato dalle aziende che producono software.

Caratteristiche di Scrum● Il team ha una propria organizzazione● Il prodotto viene realizzato in maniera iterativa e, ogni iterazione, chiamata sprint, ha una durata al più di un mese(da 2 settimane a un mese)● Non sono indicate specifiche pratiche ingegneristiche(come ad esempio nella progettazione). Le indicazioni sono solo sul processo stesso, ma non sulle tecniche specifiche.● I requisiti sono inseriti come "oggetti" in una lista chiamata product backlog

Come funziona ScrumViene utilizzata una coda dei requisiti da realizzare, chiamata product backlog, e da essa vengono estratti, seguendo anche un'ordine in base alla priorità dei requisiti, quelli che dovranno essere realizzati(almeno in potenza) nello sprint corrente.

I requisiti vengono quindi inseriti in una lista chiamata
    sprint backlog
. A questo punto il team lavora per la durata dello sprint e alla fine di esso produce un incremento del software. Durante lo sprint, le persone lavorano su iterazioni giornaliere e, giorno per giorno, si decide su cosa lavorare (su base di decisioni prese all'interno del team stesso, che poi si divide i compiti). Ogni giorno, all'interno del team, avviene un
    daily sprint meeting
nel quale si discute dei problemi e si cerca di risolverli. Al termine dello sprint c'è un feedback del cliente sulla base del lavoro prodotto. Questo processo si ripete per ogni sprint. Ruoli Fondamentali in Scrum Nel seguente schema è possibile vedere, all'interno di un processo di produzione software che adotta la metodologia Scrum, quelli che sono i ruoli diversi e di cosa si occupano. Product Owner Il product owner è quella figura che ha la responsabilità del Product Backlog, ovvero il documentoche contiene tutti i requisiti del progetto, e delle priorità dei requisiti. in base alle richieste del cliente. Definisce le caratteristiche del prodotto. Il product owner è quello che accetta o rifiuta il prodotto proposto dal team: decide se un requisito è soddisfatto o meno. Inoltre, esso è responsabile del valore di mercato del prodotto.

Team di Sviluppo

Dal punto di vista dell’esterno si presenta come un’unica unità, che però si autogestisce e sulla quale nemmeno il Product Owner, o lo Scrum Master ha potere decisionale. All’interno di esso non abbiamo una distinzione di ruoli. Non è formato da un numero elevato di persone, al più 10, ed è generalmente cross-funzionale: sviluppatori, tester, UX-Designer, etc. Il Team può cambiare membri, ma solo tra gli sprints, e lavora con i clienti per chiarimenti sui requisiti, ad esempio. Tuttavia, le richieste dei clienti non possono essere fatte direttamente al Team.

fine di ogni sprint. Sono quattro le cerimonie principali di Scrum: 1. Sprint Planning: durante questa cerimonia, il team e il Product Owner si incontrano per pianificare il lavoro da svolgere durante lo sprint successivo. Vengono definiti gli obiettivi e viene creata la lista delle attività da completare. 2. Daily Scrum: è una breve riunione quotidiana in cui il team si incontra per condividere lo stato di avanzamento del lavoro. Ogni membro del team risponde a tre domande: cosa ha fatto ieri, cosa farà oggi e se ci sono eventuali impedimenti. 3. Sprint Review: alla fine di ogni sprint, il team presenta il lavoro completato al Product Owner e agli stakeholder. Durante questa cerimonia vengono raccolti feedback e suggerimenti per migliorare il prodotto. 4. Sprint Retrospective: è una riunione in cui il team riflette sullo sprint appena concluso e identifica cosa ha funzionato bene e cosa può essere migliorato. Vengono individuati gli aspetti da mantenere e le azioni da intraprendere per il prossimo sprint. Queste cerimonie sono fondamentali per garantire una comunicazione efficace all'interno del team e per assicurarsi che il lavoro venga svolto nel modo corretto, seguendo i principi di Scrum.luso, in cui il team mostra al cliente o agli stakeholder i risultati ottenuti durante lo Sprint. Durante questa revisione vengono presentate le funzionalità sviluppate e si ricevono feedback per eventuali miglioramenti o modifiche da apportare.Sprint RetrospectiveLa Sprint Retrospective è un incontro che si tiene alla fine di ogni Sprint, in cui il team riflette sul lavoro svolto e identifica i punti di forza e di debolezza. L'obiettivo è migliorare continuamente il processo di sviluppo e individuare azioni correttive per il prossimo Sprint. Durante questa riunione vengono discussi i successi, le difficoltà incontrate e le lezioni apprese.
Dettagli
Publisher
A.A. 2021-2022
119 pagine
SSD Scienze matematiche e informatiche ING-INF/05 Sistemi di elaborazione delle informazioni

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher p.dinapoli0 di informazioni apprese con la frequenza delle lezioni di ingegneria del software e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Salerno o del prof Foggia Pasquale.