Ingegneria del software: differenze tra le versioni

Versione delle 12:43, 4 feb 2005

Versione attuale delle 15:30, 5 gen 2025

(225 versioni intermedie di oltre 100 utenti non mostrate)

Riga 1:

{{F|ingegneria del software|febbraio 2013|Voce ampia senza nessuna fonte e riferimento}}

Per '''ingegneria del software''' si intende la branca dell'[[informatica]] che si occupa di definire [[medodi]], [[formalismi grafici]] e [[strumenti]] utili a governare il [[Ciclo di vita del software|ciclo di vita]] di un [[software|prodotto software]], ovvero l'insieme delle attività da svolgere per la sua realizzazione, dall'[[analisi dei requisiti]] utente alla [[manutenzione]] dopo il [[rilascio]].

[[File:A_software_reengineering_process_model.svg|thumb|Un modello di sviluppo software]]

L' '''ingegneria del software''' ('''''software engineering''''' in [[lingua inglese|inglese]]) è quella [[Materia (didattica)|disciplina]] [[informatica]] che si occupa dei processi produttivi e delle [[Metodologia di sviluppo del software|metodologie]] di sviluppo finalizzate alla realizzazione di [[sistema software|sistemi software]]<ref>Per l'IEEE Standard 610.12-1990 è l'applicazione di un approccio sistematico, disciplinato e quantificabile nello sviluppo, funzionamento e manutenzione del software</ref>. Si propone una serie di obiettivi legati all'evoluzione dello sviluppo del software (inteso come attività [[industria del software|industriale]]) sia da un punto di vista tecnologico (per es. attraverso la definizione di nuovi [[linguaggio di programmazione|linguaggi di programmazione]]) che [[Modello di sviluppo del software|metodologico]] (per esempio il perfezionamento dei modelli di [[ciclo di vita del software]]).

== Storia ==

[[File:Algoritmo_para_Procesar_y_Organizar_en_GTD.png|thumb|Esempio di [[algoritmo]] in [[diagramma a blocchi]]]]

La necessità di creare una disciplina teorico-pratica che si occupasse in toto della realizzazione dei software nasce, intorno alla fine degli [[anni 1960|anni sessanta]], dall'esigenza di sviluppare prodotti sempre più complessi ed evoluti che rispondessero alle richieste delle grandi utenze, conferendo rigore e disciplina allo [[stato dell'arte]] dello sviluppo software nelle grandi aziende.

Più precisamente dal [[1950]] al [[1965]] lo sviluppo del software era alquanto limitato: molti programmi venivano sviluppati per [[batch]], gli informatici erano pochi ed apprendevano sul campo. Ciò che veniva sviluppato era pensato per un unico cliente, inoltre ad ogni progetto lavorava ed avrebbe lavorato una sola persona, solitamente senza scrivere alcuna [[documentazione del software]]. Fino alla nascita dell'ingegneria del software, la realizzazione di prodotti per [[computer]] era una mera attività di [[programmazione (informatica)|programmazione]] eseguita attraverso l'applicazione di discipline come:

== Metodi di analisi ==

* [[Algoritmi]]

Numerose sono le metodologie proposte per guidare l’attività dei gruppi di lavoro per lo sviluppo di un [[software|prodotto software]]. Queste sequenziano e dettagliano le attività da eseguire per portare a termine con successo il [[Ciclo di vita del software|ciclo di vita]] di un [[software|prodotto software]]. L’applicazione di queste metodologie è in parte automatizzata da una famiglia di strumenti nota come [[CASE Tool]] ('''C'''omputer '''A'''ided '''S'''oftware '''E'''ngineering).

* [[Struttura dati|Strutture Dati]]

* [[Programmazione strutturata]]

* [[Linguaggio di programmazione|Linguaggi di Programmazione]].

La [[programmazione (informatica)|programmazione]] consisteva soprattutto nel mettere insieme una sequenza di [[istruzione (informatica)|istruzioni]] di [[codice sorgente]] per realizzare compiti ben specifici.

A grandi linee tutte queste metodologie suddividono il [[Ciclo di vita del software|ciclo di vita]] in 5 macro ''attività'' ben distinte e successive: [[analisi dei requisiti]], [[progetto]] ([[progettazione|design]], nella dizione anglosassone), [[programmazione]] o [[programmazione|codifica]] ([[programmazione|programming]]), [[integrazione]] e [[test]]. In funzione della complessità del problema e del prodotto finale, queste fasi possono essere ulteriormente suddivise.

Dal [[1965]] al [[1975]] si assiste allo [[Sviluppo software|sviluppo di software]] pensato per più utenti e per i sistemi in [[sistema real-time|real-time]]. In questo periodo iniziano di conseguenza gli sviluppi di [[pacchetto (software)|pacchetti]] software ed emergono numerosi problemi, come la gestione e la manutenzione del software.

In generale durante l’[[analisi dei requisiti]] si cerca di capire quali debbano essere le carateristiche del software che si vuole sviluppare, e di ''formalizzarle'' in termini di funzionalità e requisiti tecnici. Questa formalizzazione è passata ai responsabili della [[progettazione]] per individuare gli [[algoritmi]] e le [[strutture dati]] utili alla soluzione del problema. Nella successiva fase di [[programmazione]], le soluzioni così individuate sono implementate utilizzando un [[linguaggio di programmazione]]. In funzione della complessità del prodotto finale, la [[programmazione]] può essere suddivisa tra soggetti o gruppi di lavoro distinti, ciascuno responsabile della realizzazione di una parte o [[modulo]] del [[software|prodotto software]] atteso. In questo caso è necessaria una fase di [[integrazione]] dei [[moduli]] per avere il prodotto finale. Al termine è previsto il [[test]] del prodotto prima del [[rilascio]].

Nel 1968 la conferenza [[NATO]] tenuta a [[Garmisch]], in [[Germania]], [http://homepages.cs.ncl.ac.uk/brian.randell/NATO/ rende chiaro il problema] rappresentato dall'incapacità di produrre nei tempi previsti software affidabile e rispondente ai requisiti.

Ogni attività svolta sul prodotto successivamente al rilascio è identificata come [[manutenzione]]. La [[manutenzione]] può essere [[manutenzione correttiva|correttiva]] se è finalizzata alla correzione di malfuzionamenti o [[manutenzione evolutiva|evolutiva]] se mira a realizzare nuove funzioni.

A partire dal [[1972]] e fino al [[1988]] vengono introdotte nuove tecnologie, nascono i [[Sistema distribuito|sistemi distribuiti]] e si afferma la figura del progettista del sistema informatico (quello che in seguito verrà chiamato [[architetto del software]]). Il costo dell'[[hardware]] si abbassa considerevolmente e di conseguenza la tecnologia informatica comincia a diffondersi rapidamente. Il livello qualitativo del software si eleva, tuttavia il suo sviluppo è ancora limitato a progetti scientifici e militari, e solo successivamente, dopo aver affrontato una lunga fase di [[collaudo]], il software viene introdotto nelle industrie. Organizzazioni come [[il Pentagono]] spingono fortemente lo studio di modelli che permettano di minimizzare la quantità di errori all'interno dei software.

Con l'introduzione delle tecnologie informatiche anche nel settore industriale e commerciale, a partire dal [[1988]], bacini di utenze non più tecniche sentono l'esigenza di informatizzare le proprie strutture. In questo periodo nasce la [[programmazione orientata agli oggetti]], si tende a controllare lo sviluppo del software, cercando di sviluppare prodotti di qualità, anche a causa della concorrenza affermatasi tra le [[software house]]. Si cerca di curare al massimo l'[[interfaccia grafica]] presentata all'utente, in quanto anche il tipo di utenza è cambiato. Da queste esigenze nasce l'incontro tra i [[requisiti]] dell'azienda cliente e le funzionalità che il programmatore deve realizzare.

In funzione delle relazioni organizzative tra le fasi, dal punto di vista metodologico si riconoscono due cicli di vita, illustrati nei prossimi paragrafi:

*ciclo di vita a cascata

*ciclo di vita a spirale

Si sviluppa un concetto analogo alle ottimizzazioni da catena di montaggio nelle industrie del [[XX secolo]], che avevano similmente stravolto il modo di produrre apparecchiature meccaniche. Si cerca cioè di identificare i punti focali che devono governare la realizzazione di un buon prodotto software ma soprattutto si cerca di definire formalmente cosa possa descrivere un ''buon'' prodotto software.

=== Ciclo di vita a cascata ===

A grandi linee, il '''ciclo di vita a cascata''' (''waterfall'' nella dizione anglosassone) a volte noto anche come classico, prevede che le attività vengano svolte in modo ''strettamente sequenziale''.

==Descrizione==

In generale durante l’[[analisi]] si formalizzano tutti i [[requisiti utente]]. Questa formalizzazione é passata alla [[progettazione]] per la sua soluzione che, nella successiva fase di [[programmazione|codifica]], é implementata in un [[linguaggio di programmazione]]. Infine si effettua l’[[integrazione]] ed il [[test]] del [[prodotto software|prodotto]] prima del [[rilascio]].

=== Concetti base ===

{{vedi anche|Sviluppo software}}

[[File:Development_Stages.svg|thumb|Una parte dello sviluppo software]]

L''''ingegneria del software''' identifica una formalizzazione del processo di [[Analisi dei requisiti|analisi]], [[Progettazione (ingegneria del software)|progettazione]], realizzazione e [[Manutenzione (software)|manutenzione]] di un sistema informatico.

Per tale associazione con una idea quasi [[Biologia|biologica]] di vita si parla spesso di ''ciclo di vita'' di un software, concetto che ha assunto con il passare dei decenni un'importanza sempre maggiore, abbandonando progressivamente l'idea di software come ''manufatto'' e passando ad un'idea del software come prodotto industriale. La necessità di creare una [[scienza]] che si occupi della realizzazione dei sistemi informativi nasce dalla necessità di sviluppare prodotti sempre più complessi ed evoluti che rispondano a esigenze di correttezza del prodotto finale e ad una facile manutenzione di esso.

Il software come prodotto industriale diventa anche oggetto di un attento esame per estendere le capacità di realizzazione dello stesso. Nasce in pratica un concetto simile alle ottimizzazioni da [[catena di montaggio]] per le industrie del [[XX secolo|secolo scorso]]. Si cercano quindi di identificare nella realizzazione del software, quegli obiettivi a cui tengono le industrie del software, come qualità del software realizzato e soprattutto di rilasciare un prodotto ben documentato e facilmente "manutenibile".

Così semplificato, il ciclo di vita classico può essere rappresentato come:

La nuova scienza, l'ingegneria del software, si preoccupa effettivamente di concretizzare queste esigenze, tramite la definizione di [[Modello di sviluppo del software|modelli]] che permettono a team di tecnici di realizzare in cooperazione prodotti sempre più evoluti e di qualità. L'ingegneria del software definisce quindi un insieme di processi, ovvero sequenze di fasi che individuano tappe specifiche nella realizzazione di un sistema software, tutte documentate e ispezionabili, che offrano in sostanza adeguata visibilità alle diverse tipologie degli utenti del sistema, per il controllo dei singoli prodotti e/o per l'eventuale manutenzione.

[[Immagine:ciclo_di_vita_a_cascata.gif]]

=== Le fasi dell‘Ingegneria del Software o dell’ingegneria dei sistemi ===

da cui il richiamo alla cascata che troviamo nel nome.

È possibile raggruppare in modo succinto ogni dominio dell’ingegneria del software in sole 5 fasi:

* Analisi di business e analisi dei requisiti;

A titolo di esempio, consideriamo il ciclo di vita definito con le [[MIL-STD|MIL-STD-2167]] da parte dell’autorevole [[DoD]] ([[Department of Defense]], il Ministero della Difesa Americano) per il linguaggio [[ADA]] (altro prodotto del DoD).

* Progettazione e architettura del software;

* Sviluppo software, programmazione o codificazione;

* Consegna ed assicurazione della qualità del software;

* Manutenzione correttiva-adattiva e manutenzione evolutiva;

Ricordando che queste cinque fasi che abbiamo elencato per un processo di ingegneria del software ''non dovrebbero essere prese come una regola'' o uno standard.<ref>{{Cita web|url=https://ingegneriadelsoftware.online/infografica-le-fasi-sviluppo-software/|titolo=Le 5 fasi dello sviluppo software – infografica {{!}} Ingegneria del software e analisi dei requisiti|lingua=it-IT|accesso=2020-01-13|urlarchivio=https://web.archive.org/web/20200112235923/https://ingegneriadelsoftware.online/infografica-le-fasi-sviluppo-software/|dataarchivio=12 gennaio 2020|urlmorto=sì}}</ref>

Le [[MIL-STD|MIL-STD-2167]] dividono il ciclo di vita del software nelle seguenti 6 macro attività:

* '''ANALISI''':

**''Analisi dei requisiti'': definisce cosa viene richiesto in termine di funzioni, senza specificare come esse devono essere realizzate

**''Progetto preliminare'': segue i requisiti, sviluppa un approccio al software che comprende anche modelli matematici, diagrammi di flusso funzionali e procedure di collaudo. In questa fase si definiscono la struttura generale e le operazioni del sistema, indicando anche le relazioni tra i principali blocchi funzionali (moduli)

*'''PROGETTAZIONE''':

**''Progetto esecutivo'': effettiva scomposizione gerarchica e dettagliata di tali moduli; questa scomposizione continua fino a che un’ulteriore scomposizione porterebbe al codice del programma

*'''IMPLEMENTAZIONE''':

**''Codifica e verifica'': scrittura e verifica dei programmi partendo dal progetto esecutivo e utilizzando le procedure di verifica

**''Computer Software Code'' (CSC): integrazione e verifica delle unità comprese nei singoli sottosistemi

**''Convalida dell’integrazione'' del CSC

=== Produzione software nel terzo millennio ===

Il maggior pregio di questo metodo di lavoro è certamente la semplificazione del controllo dell’andamento del progetto tramite la suddivisione del ciclo di vita in fasi successive ben definite. Le diverse metodologie che adottano questo ciclo di vita si distinguono essenzialmente per la suddivisione e specificazione delle fasi in sottofasi più elementari, nella definizione di standard di documentazione e nella individuazione di momenti di verifica al termine di ciascuna attività ('''milestone''').

{{vedi anche|Ciclo di vita del software|Modello di sviluppo del software|Metodologia di sviluppo del software}}

Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasi persegue due obiettivi:

Ancora oggi le aziende pongono l'accento sulla necessità di definire processi di [[Sviluppo software|sviluppo]] del software che consentano di rispettare le scadenze fissate per ridurre i costi di realizzazione dei prodotti stessi. Vengono identificati differenti [[Ciclo di vita del software|cicli di vita del software]], ovvero diversi processi che possono essere attualizzati da un team per giungere ad un risultato comune. Ognuno di questi differenti processi identifica una serie di passi chiave da seguire per realizzare infine un prodotto software che soddisfi i requisiti. L'ingegneria del software racchiude questi e molti altri elementi, definendo una scienza che si preoccupa effettivamente di come permettere non più ad una singola persona ma ad un team di tanti sviluppatori, di realizzare un ''buon'' software. Differenti utenze generano differenti requisiti<ref>{{Cita web|url=https://ingegneriadelsoftware.online/come-scrivere-una-user-story-fantastica/|titolo=Como escrever uma User Story fantástica {{!}} Ingegneria del software e analisi dei requisiti|autore=chicoalff|lingua=it-IT|accesso=2020-01-13|urlarchivio=https://web.archive.org/web/20200112235948/https://ingegneriadelsoftware.online/come-scrivere-una-user-story-fantastica/|dataarchivio=12 gennaio 2020|urlmorto=sì}}</ref> e nuove esigenze nella realizzazione di un software.

* assegnare a ciascuna fase la soluzione di problematiche specifiche

* rendere, per quanto possibile, le fasi indipendenti allo scopo di poterne parallelizzare le attività

Resta oggi il problema di produrre con tempi e costi prestabiliti dei sistemi software di formidabili dimensioni, enormemente cresciuti rispetto ai pacchetti software di alcune decine di anni fa. Per queste situazioni la neonata scienza si trova spesso in difficoltà e si sente il bisogno di teorie più evolute. Se l'approccio iniziale era basato sui concetti dell'industria meccanica dell'inizio del [[XX secolo]] (''tempi e metodi''), adesso si capisce che tale impostazione è insufficiente: nell'industria meccanica si parla ormai di ''fabbrica immateriale'' costituita dalle conoscenze dei dipendenti, dai rapporti tra di loro, dalle aspirazioni comuni; ancor di più ciò vale per la fabbrica software. In aggiunta molti hanno capito le caratteristiche originali del prodotto software (prima fra tutte l'immaterialità del prodotto principale - il codice eseguibile) che portano alla necessità di tecnologie meno note in altri settori: la più importante di tali tecnologie è probabilmente il ''controllo di configurazione'' (come le aziende).

Benché l’adozione di questi principi appaia estremamente produttiva, la loro applicazione pratica ha come effetto collaterale, soprattutto per i progetti di grandi dimensioni, un pericoloso scollamento fra le diverse attività, sia per le difficoltà di coordinamento che per la difformità delle metodologie e dei formalismi specialistici adottati.

Ad esempio, normalmente l’individuazione delle [[strutture dati]] e delle [[funzionalità]] del [[sistema]] sono affrontate con metodologie diverse e, soprattutto per i progetti di grandi dimensioni, contemporaneamente e separatamente da gruppi di lavoro differenti. Nel primo caso i risultati sono formalizzati con uno [[Schema Entità-Relazione]] (ER o [[Schema Entità-Relazione|Entity-Relationship diagram]] nella dizione anglosassone) nel secondo con un metodo di [[scomposizione funzionale]]. Solo quando queste due attività terminano viene avviata una ulteriore attività di armonizzazione dei rispettivi risultati.

Un ulteriore problema di questa impostazione deriva dalla necessità di terminare completamente tutta la fase di [[analisi]] e [[progettazione]] dell’applicazione per cominciare la [[programmazione]] e quindi verificarne sul campo le conclusioni.

== Ordinamento universitario ==

=== Ciclo di vita a spirale ===

=== In Italia ===

Nell'ordinamento universitario italiano esistono lauree specializzate nell'ingegneria del software. Esse si pongono come obiettivo quello di specializzare informatici nei diversi ambiti ai quali può essere applicata la disciplina: dai sistemi complessi e [[sistema real-time]], a quelli [[sistema embedded|embedded]], fino ad arrivare a quelli [[sistema distribuito|distribuiti]] ed enterprise. [[Laurea magistrale|Lauree magistrali]] in ingegneria del software sono, ad esempio, quelle dell'[[Università degli Studi dell'Aquila]]<ref>[http://gseem.eu/]</ref>, della [[Libera Università di Bolzano]]<ref>[http://em-se.eu/]</ref> e del [[Politecnico di Torino]]<ref>[https://didattica.polito.it/laurea_magistrale/ingegneria_informatica/it/presentazione]</ref> che prevedono percorsi di doppia laurea estera. Per le [[laurea triennale|lauree triennali]], invece, esistono cattedre e insegnamenti di ''ingegneria del software'' nella facoltà di scienze per i corsi di laurea in [[Informatica]], [[Ingegneria Informatica]] ed [[Informatica e tecnologie per la produzione del software]].

== Note ==

Ogni tentativo di descrivere formalmente una attività che coinvolge esseri umani dotati di libero arbitrio è destinato a produrre al più vaghe approssimazioni della realtà, e questo vale anche per lo sviluppo di software.

<references/>

== Bibliografia ==

Sotto questo punto di vista, l'ingegneria del software può essere vista come il tentativo di applicare ad una attività con forte contenuto creativo, la scrittura di software, i metodi di organizzazione del lavoro della fabbrica, con l'obiettivo di realizzare un processo con costi e tempistiche certe e risultati prevedibili.

* {{cita libro

Un grosso limite del modello "ciclo di vita a cascata" è che nella realtà i risultati delle prime fasi di sviluppo devono spesso essere rimessi in discussione, sia durante l'implementazione che dopo il rilascio, nella fase di manutenzione, con modifiche che impattano tutte le fasi del ciclo di vita.

|autore = [[Ian Sommerville]]

|titolo = Ingegneria del software

|url = https://software-engineering-book.com/

|editore = Pearson

|città = Torino

|anno = 2017

|edizione = 10

|ISBN = 9788891902245

|cid = Sommerville 2017

}}

* {{cita libro

Gli sviluppatori e gli utenti infatti non riescono a capire tutte le implicazioni delle scelte fatte in fase di analisi dei requisiti, specifica e progettazione, senza avere in mano il prodotto finito, o almeno un suo prototipo. Nel caso del software, il prototipo è una versione semplificata del prodotto che si stà realizzando, con funzionalità ridotte o anche totalmente assenti (può ridursi anche ad uno schizzo dell'interfaccia grafica su un foglio di carta, o a una simulazione del funzionamento del programma con dati calcolati a mano).

|titolo = Software Engineering — Guide to the software engineering body of knowledge (SWEBOK)

|editore = International Standards Organization

|città = Ginevra (CH)

|anno = 2015

|edizione = 2

|url = https://standards.iso.org/ittf/PubliclyAvailableStandards/c067604_ISO_IEC_TR_19759_2015.zip

|lingua = en

|id = ISO/IEC TR 19759:2015(E)

|cid = SWEBOK 2015

}}

== Voci correlate ==

La difficoltà di realizzare correttamente il software all'interno di un processo lineare ha portato anche a colossali fallimenti, con lo sforamento di tutti i vincoli di budget sia economico che temporale.

{{Div col}}

* [[Application lifecycle management]]

* [[Architettura multi-tier]]

* [[Artefatto (sviluppo software)]]

* [[Ciclo di vita del software]]

* [[Crisi del software]]

* [[Design pattern]]

* [[Gestione della configurazione]]

* [[Metriche software]]

* [[Modello di sviluppo del software]]

* [[Model-View-Controller|MVC]]

* [[Object Role Modeling]]

*[[Profilazione (programmazione)|Profilazione]]

* [[Qualità del software]]

* [[Rapid application development]]

* [[Rational Software]]

*[[Requisito funzionale|Requisito Funzionale]]

* [[Service Oriented Architecture]]

* [[Sviluppo software]]

* [[Unified Modeling Language]] (UML)

{{Div col end}}

== Altri progetti ==

L'evoluzione del metodo di sviluppo classico, o se si vuole la presa d'atto del modo di lavorare nel mondo reale, ha portato a quello che viene descritto come "ciclo di vita a spirale": le fasi del ciclo di vita classico vengono percorse fino ad ottenere una prima versione estremamente semplificata del programma; questa viene utilizzata per comprendere meglio i requisiti degli utenti, le specifiche e la progettazione, portando alla realizzazione di una nuova versione più evouta. Il processo si interrompe in teoria quando viene costruita una versione soddisfacente, in pratica quando il budget è stato eccessivamente superato.

{{interprogetto|preposizione=sull'|wikt=ingegneria del software}}

== Collegamenti esterni ==

[[Categoria:Teorie dell'informatica]]

* {{Collegamenti esterni}}

* {{FOLDOC|software engineering|software engineering}}

{{Ingegneria}}

[[ar:&#1607;&#1606;&#1583;&#1587;&#1577; &#1576;&#1585;&#1605;&#1580;&#1610;&#1575;&#1578;]]

{{controllo di autorità}}

[[de:Softwaretechnik]]

{{portale|informatica|ingegneria}}

[[en:Software engineering]]

[[es:Ingeniería de software]]

[[Categoria:Ingegneria del software| ]]

[[fa:&#1605;&#1607;&#1606;&#1583;&#1587;&#1740; &#1606;&#1585;&#1605;&#8204;&#1575;&#1601;&#1586;&#1575;&#1585;]]

[[he:&#1492;&#1504;&#1491;&#1505;&#1514; &#1514;&#1493;&#1499;&#1504;&#1492;]]

[[lt:Program&#371; in&#382;inerija]]

[[nl:Software engineering]]

[[ja:&#12477;&#12501;&#12488;&#12454;&#12455;&#12450;&#24037;&#23398;]]

[[pt:Engenharia de software]]

[[su:Rékayasa software]]

[[fi:Ohjelmistotuotanto]]

[[th:&#3623;&#3636;&#3624;&#3623;&#3585;&#3619;&#3619;&#3617;&#3595;&#3629;&#3615;&#3605;&#3660;&#3649;&#3623;&#3619;&#3660;]]

[[zh-cn:&#36719;&#20214;&#24037;&#31243;]]