Il termine "ingegneria del software" è stato usato da molte persone per significare molte cose diverse. Il campo dello sviluppo del software soffre di quella che io chiamo "inflazione di titoli di lavoro". In altre parole, molti che hanno il titolo di lavoro "ingegnere del software" non sono veri ingegneri del software, ma piuttosto programmatori (o forse un po' di più).
Cos'è dunque l'ingegneria del software? È fare tutte le cose necessarie per produrre software di alta qualità da cui qualcuno possa dipendere. Un modo per spiegare cosa sono tutte queste cose è vedere cosa dicono gli esperti del settore. Nel 1998 circa, un gruppo di organizzazioni che includeva le due maggiori società tecniche di informatica (l'Association for Computing Machinery e la IEEE computer society), insieme a circa una dozzina di grandi aziende che sviluppano software di alta qualità e altamente complesso, ha iniziato uno sforzo per definire ciò che un vero ingegnere del software deve sapere. Dopo diversi anni di intenso lavoro, questo sforzo è sfociato in un documento intitolato "Guide to the Software Engineering Body of Knowledge" (spesso indicato come SWEBOK). Questa guida è ora nella sua terza versione dopo aver avuto un'ampia revisione e revisione da parte di oltre 1000 esperti in tutto il mondo. È mantenuta dalla IEEE Computer Society e può essere acquistata da loro come libro stampato o scaricata gratuitamente come PDF su www.swebok.org.
Lo SWEBOK definisce 15 aree di conoscenza che sono considerate essenziali per la vera ingegneria del software. Ognuna di queste, a sua volta, è divisa in una dozzina di argomenti più dettagliati. Uno di questi 15 è la costruzione del software (programmazione) e gli altri sono cose come i requisiti del software, la progettazione del software, la gestione della configurazione del software, il test del software, la qualità del software, la gestione del progetto del software, e molti altri. Il documento SWEBOK ha anche un eccellente elenco di materiale di riferimento.
C'è molto coinvolto nella vera ingegneria del software. Una revisione del documento SWEBOK è un buon punto di partenza se si sta cercando di capire tutto ciò che è coinvolto nel fare vera ingegneria del software. Ma questa è solo la conoscenza di base. C'è anche la questione dell'esperienza, sia nello sviluppo di software che nella comprensione delle applicazioni per le quali si scrive software.
Nota che la vera ingegneria del software permette ad uno (o, più spesso, ad un team di ingegneri del software) di sviluppare un pacchetto software altamente complesso come quello richiesto per un sistema di controllo del traffico aereo o una centrale nucleare o un moderno aereo o automobile. Un esempio che illustra un progetto di tale portata sarebbe molto grande. Di seguito ho fornito un esempio semplificato di ciò che ci vorrebbe per ingegnerizzare il software di un'applicazione software un po' più piccola. Si basa su diversi prodotti su cui ho lavorato durante la mia carriera:
- un sistema di navigazione per una nave,
- un pacchetto software che è stato un precursore dei moderni sistemi di elaborazione testi,
- un sistema radar per elicotteri commerciali,
- un sistema operativo per un supercomputer,
- e molti altri.
Di seguito, ho elencato le attività che un ingegnere software esegue quando sviluppa una grande applicazione software veramente professionale e di alta qualità. Si noti che, sebbene abbia elencato le attività dell'ingegneria del software in un ordine particolare, molte di esse si verificano contemporaneamente l'una all'altra e, spesso, alcune di esse vengono svolte ripetutamente.
- Comprendere il problema da risolvere. Questo spesso richiede una vasta conoscenza del dominio dell'applicazione. Il software per la navigazione di navi o aerei richiede conoscenze molto diverse dal software per risolvere applicazioni aziendali, che a sua volta richiede conoscenze molto diverse dal software per un dispositivo medico critico per la sicurezza, che è molto diverso dal software per un'applicazione per smartphone.
- Comprendere le tecnologie disponibili. Quali dispositivi hardware saranno coinvolti e cosa saranno in grado di fare e cosa dovrà fare il software. Questo a volte è chiamato ingegneria dei sistemi e, nella misura in cui è necessario, richiede ingegneri che conoscano più tecnologie. All'inizio della mia carriera, gli individui che facevano questo lavoro presentavano i loro risultati al team del software, ma man mano che il software diventava sempre più importante nella progettazione di sistemi complessi, gli ingegneri del software diventavano sempre più responsabili e coinvolti in questa attività.
- Prendere decisioni su quali strumenti di sviluppo del software, linguaggi e metodologie di sviluppo abbiano più senso. Questa è un'attività di analisi e pianificazione che richiede la conoscenza di più linguaggi, strumenti e metodologie. Non basta prendere il proprio linguaggio di programmazione preferito e andare con quello. Per esempio, potresti usare un computer per il quale il tuo linguaggio preferito non ha un compilatore o il tuo linguaggio preferito potrebbe essere poco adatto all'applicazione.
- Partecipare alle decisioni su quali parti del software dovrebbero essere sviluppate da quali organizzazioni (nel caso di un grande progetto, ci possono essere più organizzazioni coinvolte). Queste organizzazioni potrebbero non essere tutte parte della tua azienda. Se parte del software deve essere acquistato o sviluppato da un'altra organizzazione, potresti anche aver bisogno di essere coinvolto nello stabilire e negoziare gli obblighi contrattuali e altri requisiti che imporrai a questi fornitori.
- Decidere su come il software sarà suddiviso in pacchetti indipendenti, spesso conosciuti come "elementi di configurazione". Cioè, quali saranno le parti principali.
- [Anche se non è una funzione di ingegneria del software di per sé, ti potrebbe anche essere richiesto di aiutare a scrivere proposte a potenziali clienti, spiegando come svilupperai il tuo software e perché il tuo è un approccio appropriato per la specifica applicazione. Spesso, i grandi progetti vengono messi in competizione da diverse aziende che hanno le competenze appropriate.]
- Determinare i requisiti per il software e come questi siano riconducibili a requisiti di sistema di livello superiore. Tipicamente, i requisiti sono prima stabiliti dai clienti o da ingegneri di livello superiore che li definiscono nella loro terminologia. L'ingegnere del software deve tradurli in una terminologia che abbia senso per gli sviluppatori del software. Spesso, questo comporta molte discussioni e persino dibattiti con i clienti e altri per appianare i dettagli e determinare esattamente ciò che è richiesto. Un problema comune è che i clienti non sanno veramente cosa vogliono o, in un grande progetto, che diverse parti dell'organizzazione del cliente hanno opinioni diverse su quali dovrebbero essere i requisiti. E' anche essenziale stabilire un approccio di gestione del cambiamento dei requisiti. I requisiti vengono cambiati frequentemente (di solito dai clienti, ma occasionalmente dagli ingegneri che si rendono conto che i requisiti originali sono troppo costosi o tecnicamente non fattibili). Devi essere in grado di capire le conseguenze dei cambiamenti proposti sul costo e sul programma del software in modo che quando i cambiamenti sono proposti puoi far conoscere le conseguenze a coloro che prendono le decisioni, come i clienti o i manager di livello superiore (tipicamente, i cambiamenti richiedono slittamenti del programma e aumenti dei costi).
- Sviluppare un piano completo per sviluppare il software. Prendendo in considerazione questioni come il budget disponibile, i vincoli di tempo e gli obiettivi di pianificazione, i rischi e le risorse disponibili, si deve ideare un piano su come sviluppare il software. Questo aiuta a sapere di quante persone e di quali attrezzature si ha bisogno, così come di quanti soldi e tempo si ha bisogno. Sebbene un buon piano richieda che tu abbia una ragionevole comprensione dei requisiti, spesso devi fare gran parte della tua pianificazione come parte del passo 6 (sopra), perché i clienti spesso decidono quale appaltatore usare in base alla qualità dei loro piani di sviluppo del software.
- Sviluppare l'architettura del software. Questo in realtà inizia ai passi 4 e 5 (sopra), ma qui bisogna definire molti dettagli.
- Sviluppare il design dettagliato del software. Questo è il momento in cui si arriva a tutti i dettagli più fini ma molto importanti.
- Scrivere il codice. Finalmente, al passo 11, si inizia a programmare.
- Sviluppare un efficace piano di integrazione e test per il prodotto e il software. Anche questo inizia prima, ma dopo l'inizio della programmazione le attività di integrazione e test diventano importanti. In un progetto di grandi dimensioni, è fondamentale averci pensato bene.
- Condurre i processi di integrazione e di test e, quando si riscontrano problemi, capire cosa è andato storto e perché e rifare tutti i passi precedenti che devono essere rifatti per risolvere i problemi.
- Determinare come il prodotto sarà consegnato, installato, mantenuto e aggiornato una volta nell'ambiente del cliente. Poi implementare tutti gli strumenti e le capacità necessarie per far sì che ciò accada. (Pensate a tutte le cose necessarie per far funzionare correttamente gli aggiornamenti del software, per esempio.)
- Determinare quali criteri di qualità sono appropriati per il prodotto e implementare varie revisioni, ispezioni e altri meccanismi per valutare la qualità e assicurare che gli standard di qualità siano soddisfatti. [Questa attività inizia anche molto prima e in parallelo con gran parte di quanto sopra]. Questo implica cose come le convenzioni di denominazione per le versioni del software e i componenti del software, i metodi per autorizzare le modifiche e assicurarsi che le modifiche non si sovrappongano e causino problemi, assicurarsi che la versione giusta di ogni componente sia quella usata per ogni versione o rilascio del prodotto, ecc.
- Documentare molte cose lungo il percorso in modo che coloro che devono mantenere e supportare il prodotto dopo che tu sei andato avanti possano capire tutti gli aspetti di tutto ciò.
Ci sono molte cose che ho lasciato fuori da quanto sopra, alcune delle quali potrebbero applicarsi solo ad alcuni progetti. Un piccolo progetto come un sito web o una tipica app per smartphone potrebbe non richiedere un approccio così esteso come quello che ho descritto qui, ma avete chiesto cosa sia l'ingegneria del software e ho pensato di darvi un'idea di ciò che i veri ingegneri del software professionisti passano il loro tempo a fare.
Devo anche menzionare che alcuni metodi di sviluppo del software, come i metodi "agili", sono altamente iterativi, il che significa che passano attraverso molto di quanto sopra ripetutamente, anche se non necessariamente con un alto grado di disciplina e rigore per ogni iterazione.
Devo anche menzionare che un progetto di ingegneria del software veramente grande coinvolge un grande team di persone e le capacità di gestione delle persone saranno richieste a tutti i partecipanti, specialmente ai team leader e ad altri con livelli di responsabilità più alti.