Menu
Riflesso della tua esperienza,
che trova nell’ordine e nella precisione
un processo di sviluppo di successo
Riflesso della tua esperienza,
che trova nell’ordine e nella precisione
un processo di sviluppo di successo
Riflesso della tua esperienza,
che trova nell’ordine e nella precisione
un processo di sviluppo di successo
Il tuo modo di organizzare il lavoro è il riflesso della tua esperienza, sia lavorativa che culturale. Vale lo stesso per le tue relazioni con i clienti o con i colleghi: ognuno di noi ha un proprio processo di sviluppo e spesso riesce a trovare ordine e precisione soltanto seguendo il suo istinto.
La struttura di un processo di sviluppo viene influenzata da vari fattori, come ad esempio le relazioni tra fornitore e committente, il sistema IT e quello di gestione delle risorse umane.
Questo significa che la modifica o innovazione di un processo deve tenere conto di questi aspetti, migliorando le situazioni critiche e senza stravolgere le parti più solide.
In informatica un modello di sviluppo software è il principio teorico che indica il metodo da seguire nel progettare e nello scrivere un programma. Il modello è alla base di una metodologia di sviluppo.
I modelli di sviluppo software simulano la realtà per vedere cosa accadrebbe e al fine di ridurre gli errori e ottimizzare prestazioni e risultati.
Le fasi principali del modello di sviluppo nascono tra gli anni ’60 e ’70, anche se con costi di manutenzione troppo elevati, dovuti alla rigidità dei processi.
In questo caso parliamo del modello a cascata, il ciclo di vita del software più tradizionale.
Il modello o ciclo di vita a cascata (waterfall model in inglese o waterfall lifecycle) è il primo modello di ciclo di vita del software: per la prima volta lo sviluppo viene visto come processo industriale, abbandonando quello “artigianale” che prevedeva una programmazione basata su tentativi ed errori. Il ciclo di vita a cascata, grazie al suo successo negli anni ’70, viene associato ancora oggi alla programmazione procedurale e strutturata.
Il “waterfall model” prevede un processo strutturato in sequenze lineari, composto da:
Analisi dei requisiti: viene deciso cosa farà il sistema secondo uno studio di fattibilità, dove vengono analizzati costi tecnici ed economici per capire se valga la pena realizzare il sistema con i suoi requisiti.
Progettazione: dopo aver stabilito (nella prima fase) lo scopo del sistema, si progetta la sua suddivisione in moduli, relazioni tra moduli comprese.
Sviluppo (o codifica): creazione dei moduli con un linguaggio di programmazione.
Collaudo: vengono fatte delle prove per verificare che i singoli moduli implementati funzionino.
Manutenzione: comprende le attività volte a migliorare, estendere e correggere il sistema nel tempo.
Un’organizzazione può formalizzare ulteriormente il processo imponendo vincoli sulla natura, sul formato e sulla struttura dei documenti prodotti nelle varie fasi, per poter analizzare meglio lo stato di avanzamento del progetto e la qualità del lavoro svolto.
Il modello a cascata è stato poi abbandonato dall’industria del software: negli anni 80 il software stesso si è evoluto, dando vita a nuovi linguaggi di programmazione, critiche e revisioni.
Questi cambiamenti hanno trasformato il modello a cascata in modello evolutivo, che prevede una prima fase più ridotta in grado di ottenere migliori requisiti, chiamata prototipazione.
Si è poi passati al modello trasformazionale, che approfondisce e migliora l’analisi dei requisiti per produrre alla fine un prototipo funzionale.
Le varie fasi di un processo di sviluppo sono caratterizzate da ulteriori processi svolti all’interno; la prima fase prevede lo studio di fattibilità, che ha lo scopo di decidere se intraprendere il nuovo sviluppo.
Cliente e organizzazione aziendale sono gli attori coinvolti, coloro che producono il primo output.
Gli attori ricercano le soluzioni esistenti e individuano i problemi principali:
Superati questi ostacoli, viene scritto un documento con diversi scenari e soluzioni, accompagnato da una discussione dei compromessi in termini di costi previsti e benefici: il documento di studio di fattibilità.
Con lo scopo di identificare e descrivere i requisiti (le caratteristiche del sistema), al cliente e all’organizzazione aziendale si aggiungono gli sviluppatori.
Gli attori coinvolti emettono un documento che descrive le caratteristiche del sistema, le esigenze dell’utente e la fattibilità per il progettista. Documento che deve essere preciso, completo, coerente e modificabile.
Successivamente viene definita la struttura di massima (architettura di alto livello), così come le caratteristiche dei singoli componenti (moduli).
L’individuazione dei componenti necessari e delle loro caratteristiche spesso comporta problemi riguardanti le numerose decisioni da prendere, le strutture diverse, le scelte non chiare e i test di modulo.
Una volta ottenuto un sistema funzionante, si passa all’Alpha test per la verifica e la validazione del processo.
I problemi tipici riguardano:
Il beta test viene svolto dagli utenti, che verificano il software. È un ciclo lungo che può essere suddiviso in:
Lo sviluppo di un software è cambiato rispetto a quello “a tentativi”, stabilendo due concetti principali:
A semplificazione del controllo dell’andamento del progetto grazie a un ciclo di vita in fasi, rappresenta il vantaggio principale di questo metodo di lavoro.
Per ottimizzare il ciclo di vita, la scomposizione delle fasi ha due obiettivi:
Il modello è una semplificazione della realtà che deve però rispettare tre principi:
Linearità: spesso si hanno cicli di feedback per la correzione degli errori che devono essere lineari. Non si può saltare all’indietro per correggere, è necessario seguire la linea sequenziale.
Rigidità: quando si passa alla fase successiva, la fase precedente viene ufficialmente “superata”, motivo per cui clienti e sviluppatori non possono interagire dopo la parte iniziale;
Monoliticità: siccome il modello è orientato alla data di rilascio che spesso si pone a mesi o anni dopo l’inizio della prima fase, gli eventuali errori commessi o i cambiamenti dei requisiti verranno corretti dopo la fase di consegna, rendendo il software già obsoleto con le modifiche che andranno fatte.
Un processo come questo comporta vari problemi, come ad esempio:
Tutto questo riesce a spiegare gli alti costi del software, con le specifiche poco complete e i troppi interventi successivi per introdurre funzionalità non previste in partenza.
Per migliorare questo modello, sempre più aziende si stanno orientando verso il lavoro Agile.
Negli ultimi anni la produzione si è dovuta adattare a nuovi fattori, vedi la competizione elevata e le continue richieste di qualità e velocità. Fattori che hanno cambiato la natura dei progetti, rendendo insufficiente il management tradizionale.
Per aiutare le realtà meno forti a sopravvivere, sono state inventate tecniche evolute di project management: il metodo AGILE e SCRUM.
Il metodo Agile (Lightweight methodologies) nasce nell’IT a metà degli anni ’90 per mostrare un’evoluzione rispetto al tradizionale metodo Heavyweight.
I principi fondamentali di un processo Agile sono:
L’idea del Metodo Agile si basa sulla possibilità di realizzare un progetto per fasi, chiamate “sprint”. Ogni sprint corrisponde a un output, con l’introduzione di una nuova funzionalità verificata dal cliente, che vede il lavoro svolto fino a quel punto.
Questo sistema consente di modificare facilmente il progettoabbattendo i costi di produzione ed evitando il fallimento del progetto.
Scrum è il metodo Agile più diffuso, soprattutto nei progetti complessi. Il processo di gestione di un progetto in sprint viene diviso per poter coordinare il processo di sviluppo del prodotto insieme al cliente. Solitamente gli sprint durano da 2 a 4 settimane.
Questo metodo nasce per controllare i processi dove la conoscenza deriva dall’esperienza e le decisioni vengono prese seguendo ciò che si conosce. Sprint dopo sprint, il metodo Scrum aumenta la prevedibilità ed il controllo del rischio.
Le componenti principali di SCRUM si dividono in: ruoli, artefatti ed eventi.
In uno Scrum Team ci sono tre ruoli, che lavorano insieme per un continuo e veloce flusso di informazioni.
SCRUM MASTER: il responsabile del processo, deve garantire che il processo venga eseguito con successo. Il team deve lavorare in maniera coerente eliminando ostacoli esterni.
PRODUCT OWNER: conosce tutti i requisiti del prodotto e porta avanti gli interessi del processo. Deve massimizzare il valore del prodotto e del Team di Sviluppo.
TEAM DI SVILUPPO: il gruppo di professionisti che si occupa dello sviluppo del prodotto e del testing delle funzionalità, organizzando le priorità per portare a termine un determinato sprint.
Gli artefatti sono 3, progettati per avare più informazioni chiave e monitorare il processo.
PRODUCT BACKLOG: documento con i requisiti necessari per la realizzazione del progetto. Il Product Owner è responsabile del contenuto e della disponibilità.
SPRINT BACKLOG: documento con le task da completare negli sprint. Viene definito il lavoro necessario per raggiungere gli obiettivi dello sprint.
INCREMENTO: la somma degli elementi del Product Backlog completati durante uno sprint e quelli precedenti. L’incremento, in base agli accordi col team di Sviluppo, dovrà garantire un prodotto utilizzabile.
Gli eventi principali in Scrum sono 4, creati per sincronizzare le attività e ridurre al minimole difficoltà. L’obiettivo è quello di monitorare l’andamento del progetto in modo chiaro e preciso.
SPRINT PLANNING: il Product Owner stila il Product Backlog e, insieme al Team di Sviluppo e allo Scrum Master, individua l’obiettivo da raggiungere nello sprint seguente. Al termine della riunione lo Scrum Master può compilare lo Sprint Backlog.
DAILY SCRUM: un breve “Stand up meeting”, un confronto giornaliero (della durata di 15 min) fra il Team di Sviluppo e lo Scrum Master, nel quale si analizzano le attività del giorno precedente e si espongono le attività imminenti della giornata, compresi problemi o difficoltà.
SPRINT REVIEW: una revisione dopo ogni sprint per capire se e come è stato raggiunto l’obiettivo. Partecipa tutto lo Scrum Team e il committente del prodotto, che analizzerà il lavoro svolto fino a quello sprint.
SPRINT RETROSPECTIVE: un’ulteriore analisi di tutto lo Scrum Team per valutare cosa continuare, cosa smettere di fare e cosa migliorare nello sprint successivo.
Queste metodologie, applicate alla produzione di software, diventano vantaggiose per ogni sistema aziendale che deve gestire progetti innovativi e complessi.
Ancora una volta, prima delle macchine, dei processi e degli strumenti, ci sono le persone.
TELEFONO:
347 2948993
Lunedì – Venerdì:
09:00 – 13:00 | 14:00 – 18:00
E-MAIL:
info@newvola.it
© Copyright Newvola S.r.l. | P. IVA 11268660013
Indirizzo mail info@newvola.it | Sede Via Circonvallazione 5, 10015 Ivrea (TO) | Ufficio 347 2948993 | Privacy e Cookie Policy | ITCore Group