La tua guida completa allo sviluppo software di tutte le cose
Pubblicato: 2020-08-13Quanto sono simili un piano di produzione di fabbrica e un ufficio di sviluppatori di software?
Immagina una stanza piena di programmatori che digitano codice nei loro computer. E se trattassi il loro output come widget assemblati da una catena di montaggio di fabbrica? Le cose che massimizzano la produzione funzioneranno anche qui? O il processo di sviluppo è più simile ad altre discipline ingegneristiche?
I project manager hanno cercato di risolvere questo problema da quando è iniziato lo sviluppo del software. Da queste domande è emersa la definizione del ciclo di vita dello sviluppo del software.
Che cos'è lo sviluppo del software?
È il processo di creazione del software da zero. Sebbene la scrittura del codice sia l'attività principale, è molto di più.
Il processo di sviluppo include l'ideazione e la progettazione prima di scrivere qualsiasi codice. La pianificazione è facile da trascurare. Non sembra sviluppo nel modo in cui lo fa scrivere codice. Eppure rispondere a domande cruciali prima rafforza il prodotto finito. Vale la pena perseguire il progetto? Se sì, qual è il modo migliore per farlo? Quali caratteristiche sono necessarie e quali caratteristiche è bello avere? Le risposte danno al progetto maggiori possibilità di successo.
Sebbene i passaggi siano costanti, la loro applicazione varia. Il motivo per cui lo sviluppo del software è una nuova disciplina. Le discipline ingegneristiche sono mature con centinaia di anni di storia. Lo sviluppo del software risale solo alla fine degli anni '40. È ancora una nuova disciplina. Il metodo agile ha solo 20 anni. Eppure è una delle cose più influenti accadute nella teoria della creazione del software. Indipendentemente da ciò, le sei fasi del ciclo di vita dello sviluppo del software sono comuni a tutti i sistemi.
6 fasi del ciclo di vita dello sviluppo del software (SDLC)
Un team di sviluppo può utilizzare il ciclo di vita dello sviluppo del software su un intero progetto o su una caratteristica. L'evoluzione dell'uso dell'SDLC ha riguardato la riduzione del rischio accorciando la lunghezza di ogni passaggio. Tra un momento, esamineremo di più le diverse metodologie. Per prima cosa, esaminiamo i passaggi stessi.
Inoltre, vale la pena notare che vedrai delle varianti in termini di numero di passaggi o dei loro nomi. A volte i passaggi vengono uniti, come lo sviluppo e il test. Altre volte, vedrai un passaggio diviso in due, come la pianificazione che diventa pianificazione e analisi. Nel nostro caso, rimarremo con questi sei poiché definiscono chiaramente le fasi.

1. Pianificazione
La fase di progettazione è il passaggio più importante. Le parti interessate devono considerare tutto, compresa la fattibilità del progetto stesso. Va bene uccidere l'intero progetto qui. Un'organizzazione sana consentirà alle parti interessate di farlo, se necessario. I programmatori avranno meno coinvolgimento durante questa fase in un contesto aziendale. I proprietari di prodotti, gli analisti aziendali e altre parti interessate esprimono le loro esigenze in questo passaggio.
2. Progettazione
La fase di progettazione è il passaggio più importante. Le parti interessate devono considerare tutto, compresa la fattibilità del progetto stesso. Va bene uccidere l'intero progetto qui. Un'organizzazione sana consentirà alle parti interessate di farlo, se necessario. I programmatori avranno meno coinvolgimento durante questa fase in un contesto aziendale. I proprietari di prodotti, gli analisti aziendali e altre parti interessate esprimono le loro esigenze in questo passaggio.
3. Sviluppo
La fase di progettazione include anche la progettazione dell'esperienza utente (UX). Se l'applicazione ha componenti rivolti all'utente, la progettazione dell'esperienza utente è un must. Ciò include la ricerca degli utenti osservando persone reali interagire con i modelli di prodotto. Il motivo per cui ciò accade nella fase di progettazione anziché nella fase di sviluppo è la tempistica. Le sessioni utente richiedono tempo. Spesso dai dati raccolti si verificano anche più discussioni avanti e indietro con gli stakeholder aziendali.
4. Test
Successivamente, il team di sviluppo verifica il codice. Lo scrittore di codice e il tester dovrebbero essere persone diverse. Ancora meglio è un tester di garanzia della qualità non sviluppatore. Gli sviluppatori tendono a pensare solo a scenari di percorso felice. I professionisti dei test di QA dedicati tendono ad essere più bravi a pensare a come possono violare il software. È più probabile che trovino bug prima della distribuzione in questo modo. Il risultato è un software più stabile al momento del rilascio.
Test automatici e manuali
Gli unit test e i test di integrazione sono spesso automatizzati. Spesso una piattaforma DevOps esegue questi test sul nuovo codice prima di unirlo al ramo principale.
Il test manuale è tutt'altro che obsoleto. I test automatici fanno sempre la stessa cosa. Tuttavia, una persona che esegue test manuali può trovare bug per caso durante il test. È la variabilità nei test manuali che è il suo punto di forza.
Test unitario
Uno unit test verifica solo un metodo, niente di più. La funzione sottoposta a test è il confine. Lo sviluppatore scrive gli unit test e alcuni framework SDLC li impongono. Extreme Programming li richiede. Prescrive anche uno sviluppo basato su test. Questa è la pratica di scrivere prima gli unit test. Quindi scrivendo il codice del programma effettivo.
Test d'integrazione
I test di integrazione controllano le sezioni o le funzionalità della codebase. Di solito sono automatizzati ed eseguiti dalla piattaforma DevOps. Ciò che verificano si estende su più di un singolo metodo. Un esempio è la verifica che una chiamata API abbia reso persistente un nuovo record in un database. Confrontalo con uno unit test che verifica anche il metodo API. Lo unit test sarebbe solo in grado di verificare che una chiamata al database dovrebbe avvenire. Il test di integrazione può dimostrare che i dati sono passati attraverso l'applicazione come previsto.
Test di sistema
La forma finale di test è il test completo del sistema. Per ricapitolare, unit test verifica solo una funzione. Il test di integrazione verifica una funzionalità. Ma il test di sistema tratta l'intera applicazione come una singola unità. Il test del fumo è una forma leggera di test del sistema. In esso, il tester interagisce con il sistema come potrebbe fare un utente naturale e si assicura che si comporti come previsto. In contrasto con il test completo del sistema end-to-end, che è più rigoroso. Un test completo del sistema controlla tutte le parti di un sistema come una singola entità. Inoltre, una suite di test di integrazione può fungere da test di sistema completo.
5. Distribuzione
La fase di distribuzione sta spingendo il codice testato in produzione. L'automazione della distribuzione la rende più affidabile. Inoltre, la pratica delle distribuzioni di produzione aumenta anche le probabilità di una distribuzione regolare. Il team di sviluppo si esercita con un ambiente di test chiamato ambiente di staging. Dovrebbe essere identico a quello di produzione. Più i due ambienti sono simili, maggiore è il valore dell'implementazione pratica.
6. Manutenzione
Tutto fino a questo punto nell'SDLC sarà solo circa un quarto del costo totale di proprietà. Il costo di sviluppo iniziale del software è il 25% di quanto spenderà l'azienda. La fase di manutenzione costerà all'azienda circa il 75% del costo totale di proprietà. La difesa contro l'aumento dei costi di manutenzione è più attenta alle fasi precedenti. Ciò significa una migliore progettazione tecnica, sviluppo e test più approfonditi. L'alternativa è il debito tecnico. Come il debito reale, diventa più costoso nel tempo.
5 principali metodologie di sviluppo software
Sebbene i passaggi di SDLC siano invariati, la loro implementazione e l'ordine di esecuzione variano. Diamo un'occhiata ai modi più popolari in cui le organizzazioni eseguono il processo di sviluppo del software.
1. Agile
Ciò che rende Agile unico è l'attenzione alle persone. Le metodologie Agile hanno rifocalizzato l'attenzione del settore. In precedenza, l'attenzione era rivolta al prodotto, al software. Agile lo ha sfidato e si è concentrato sulle persone che eseguono il processo. Inoltre, prima del Manifesto Agile, Extreme Programming (XP) e Scrum non avevano alcun collegamento. Eppure, in seguito, i loro praticanti si sono uniti sotto la bandiera Agile.
Agile non è un framework in sé. È un framework per framework. Al centro, si tratta di concentrarsi sulle persone e su iterazioni rapide. È esattamente quello che dice il nome, agile. Fatto bene c'è flessibilità nel raggiungere il risultato. I processi non vengono mai eseguiti a spese delle persone, che ne traggono invece valore.

Un altro tenant chiave di Agile è un approccio iterativo. L'idea è di fare blocchi di lavoro in periodi di tempo più brevi. In questo modo l'azienda può adattarsi più rapidamente ai cambiamenti del mercato. La capacità di cambiare rapidamente la direzione dello sviluppo è ciò che lo rende agile. Allo stesso tempo, il team di sviluppo può imparare da ciò che ha fatto in ogni iterazione e migliorare. I team Agile lo fanno in riunioni retrospettive dopo ogni iterazione.
2. Programmazione estrema
La programmazione estrema (spesso abbreviata in XP) ha avuto inizio all'inizio degli anni '90. Martin Fowler è stato uno dei firmatari originali del Manifesto Agile. Pensa che Agile abbia ottenuto la sua popolarità grazie al framework XP. Inoltre, sostiene che sia il modo migliore per iniziare a sviluppare software Agile.
XP prende il nome dal suo approccio. Richiede buone pratiche software comuni e le richiede. Questo è ciò che lo rende "estremo". XP richiede cose come unit test, programmazione di coppia, rilascio più spesso.
Ciò che rende XP un metodo unico è:
- Cicli di iterazione brevi (comune da 1 a 2 settimane)
- Apertura alla sostituzione degli elementi di lavoro nell'iterazione corrente (qualcosa che Scrum non consente)
- Enfasi sul test automatizzato e sulla programmazione delle coppie
3. Magra
Lean non era Agile tecnicamente, ma in pratica ha una sensazione simile. Ora è accettato dalla maggior parte delle persone come parte di Agile. Il suo focus è diverso dall'Agile tradizionale. Secondo il manifesto Agile, "Individui e interazioni su processi e strumenti". Lean si concentra più sul software che sui produttori.
Le sue radici sono i principi di produzione snella di Toyota. Ecco le sette parti che lo definiscono. Se hai familiarità con la produzione di Lean, questi suoneranno in modo simile. Sono:
- Eliminate lo spreco
- Amplifica l'apprendimento
- Decidi il più tardi possibile
- Consegna il più velocemente possibile
- Potenzia la squadra
- Costruisci l'integrità
- Ottimizza il tutto
4. Mischia
Scrum è il metodo Agile più popolare. Secondo il 14° rapporto State of Agile, il 58% delle società di software utilizza Scrum. Se includi gli ibridi Scum, la percentuale salta all'84%. Il che pone la domanda, perché è il più popolare?
La risposta è che Scrum si basa sull'ottenere più lavoro in meno tempo. Questo fa appello alle imprese. Ogni iterazione in Scrum è uno "sprint". Il nome rafforza l'idea di velocità. Di solito, uno sprint dura da 2 a 3 settimane. Una volta che un team Scrum ha pianificato uno sprint, nessuno dovrebbe modificarlo. Il nuovo lavoro deve aspettare fino all'inizio del prossimo sprint. Ciò richiede disciplina da parte degli stakeholder aziendali. In pratica, questa regola di Scrum viene spesso violata. Ecco perché i team riferiscono di fare spesso un ibrido Scrum.
Un'altra caratteristica di Scrum è lo Scrum Master. Questo è un membro del team nominato per essere incaricato di mantenere lo sprint sul bersaglio. Spesso, lo Scrum Master è uno sviluppatore del team di sviluppo.
La variante più comune di Scrum è ScrumBan, che è un mashup di Scrum e Kanban. Kanban ha le sue radici nel processo di produzione giapponese Toyota come Lean. È un sistema di lavoro just-in-time.
Ogni elemento di lavoro è come un'iterazione tutta sua. Uno sviluppatore lavora solo su una cosa alla volta. La regola è un elemento "in corso" per sviluppatore. Questo rigoroso limite di work-in-progress fa luce su eventuali colli di bottiglia. Gli sviluppatori tengono traccia degli elementi di lavoro in corso tramite una scheda Kanban. Come nota a margine, ecco da dove deriva il nome. In giapponese, Kanban significa "cartello".
5. Cascata
Il metodo a cascata è la prima di tutte le pratiche di sviluppo software. Precede Agile di almeno diversi decenni. Anche questo metodo è più vecchio del suo nome.
È il modo naturale in cui le aziende hanno sempre lavorato. È un processo lineare e inizi dall'inizio. In primo luogo, le parti interessate compilano i requisiti. Non lo stanno facendo per una o due funzionalità. No, le parti interessate aziendali esaminano l'intero progetto in una volta. Successivamente, inizia il lavoro. Gli sviluppatori fanno tutto il lavoro senza alcuna iterazione fino al completamento.
La via della cascata è la più facile da capire concettualmente. Le persone fanno una cosa alla volta. Detto questo, è il più rischioso per il successo aziendale. Se qualcosa è fuori bersaglio, le parti interessate non possono correggerlo fino al completamento del progetto. Il motivo è che non verrà nemmeno notato fino al completamento del progetto.
3 sottotipi principali di software
Il software finito è uno dei tre tipi. Questi tipi sono software di sistema, di programmazione e applicativo. Per illustrare, ecco un'analogia con la cottura di torte. Un mixer o una spatola è il software di programmazione. Ti consente di creare più torte o più applicazioni software in questa analogia. Quando si assembla una torta, lo strato inferiore è il software di sistema. È il fondamento. Senza di essa, non puoi avere una torta a strati. Lo strato superiore sarebbe quindi il software applicativo. È ciò che è visibile alla maggior parte degli osservatori casuali.
Software di sistema
Il sistema operativo di un computer è un software di sistema. È fondamentale per l'utilità di esso. Immagina un computer senza un sistema operativo. Saresti in grado di interagire con esso solo tramite il linguaggio macchina. Questo è puro binario: solo uno e zero. Troveresti impossibile lavorare con qualsiasi livello di scala. Il software di sistema apre l'utilità di un computer.
Windows, macOS e Linux sono gli esempi più popolari di software di sistema. I driver di dispositivo sono anche software di sistema. Estendono le funzionalità di base di un sistema operativo. I dispositivi intelligenti senza un sistema operativo utilizzano il firmware per abilitare la loro funzionalità. È anche un software di sistema.
Software di programmazione
Il software di programmazione è un sottoinsieme del software applicativo. Qualsiasi programma utilizzato da uno sviluppatore per creare nuovi programmi verrebbe classificato. Si va da semplici editor di testo a complessi ambienti di sviluppo integrati (IDE). La maggior parte degli sviluppatori preferisce strumenti software di programmazione più complessi. Programmi come Visual Studio di Microsoft aiutano a velocizzare lo sviluppo.

Software applicativo
Il software applicativo è il tipo più comune. È il software che ti permette di fare cose con un computer. Rende utili i computer. Esempi popolari sono programmi come Microsoft Word ed Excel.
Anche il software cloud rientra in questa categoria. Google Docs, Dropbox e persino Instagram sono software applicativi. Se ti senti confuso se qualcosa è un software applicativo o meno, ecco un semplice test. Il programma ha bisogno di qualcos'altro per funzionare? Windows o Android no. Sono software di sistema. PowerPoint, o anche un gioco come Call of Duty, hanno bisogno di altre cose in esecuzione per funzionare, il che significa che sono software applicativi. Senza driver di dispositivo e un sistema operativo, non possono essere eseguiti.
Conclusione
I metodi di sviluppo del software stanno ancora maturando. Tuttavia, indipendentemente dal metodo utilizzato, i passaggi rimangono gli stessi. I team agili possono scorrere su di loro più velocemente e i praticanti di Waterfall si spostano lentamente da uno all'altro. Tuttavia, per creare un software migliore, è necessario rafforzare il processo in ogni passaggio. Si basano l'uno sull'altro. Il ciclo di vita dello sviluppo del software non è una cosa senza uno dei suoi passaggi. Le parti fanno il tutto.
Pensa a cosa accadrebbe se lasciassi un passo fuori. Senza pianificare cosa stai facendo? Senza progettazione, il processo di sviluppo sarà casuale. Tralasciare la fase di sviluppo è impossibile. La mancanza di test garantisce che il prodotto non funzioni come previsto. Se non c'è distribuzione, nessuno avrà accesso per utilizzare il prodotto. Un'applicazione non mantenuta cade in disuso. Ogni passaggio è cruciale per il successo di un prodotto software.