Ingegneria del software: differenze tra le versioni

Versione delle 01:08, 8 feb 2005

Versione attuale delle 15:30, 5 gen 2025

(219 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:

==Storia==

La necessità di creare una disciplina che si occupi della realizzazione dei software nasce, intorno alla fine degli anni '60, dall'esigenza di sviluppare prodotti sempre più complessi ed evoluti che rispondano a richieste di grandi utenze.

Il software come prodotto industriale, diventa anche oggetto di un attento esame per evolvere la capacità di realizzazione dello stesso.

Nasce in pratica un concetto simile alle ottimizzazioni da catena di montaggio per le industrie del secolo scorso che avevano similmente stravolto il modo di produrre apparecchiature meccaniche.

Si cerca di identificare quei punti focali che devono governare la realizzazione di un buon prodotto software e soprattutto si cerca di definire formalmente cosa possa descrivere un ''buon'' prodotto software.

Fino alla nascita dell'ingegneria del software, la realizzazione di prodotti per computer era una mera attività di programmazione eseguita attraverso l'applicazione di discipline come:

* [[Algoritmi]]

* [[Struttura dati|Strutture Dati]]

* [[Programmazione Strutturatastrutturata]]

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

Con l'avvento delle tecnologie informatiche anche nel settore industriale e commerciale, bacini di utenze non più tecniche si trovano a sentire l'esigenza di informatizzare le proprie strutture. Nascono l'incontro tra i [[requisiti]] dell'azienda cliente e le funzionalità che il programmatore deve realizzare.

Fino a questo stadio, la [[programmazione]] consisteva soprattutto nel mettere insieme una sequenza di istruzioni di codice per realizzare compiti ben specifici.

Differenti utenze generano nuove esigenze nella realizzazione di un software.

Le aziende pongono ad esempio l'accento sulla necessità di definire processi di sviluppo del software che permettano di rispettare le scadenze fissate per ridurre i costi di realizzazione die prodotti stessi.

Altri processi, voluti ad esempio da organizzazioni come il Pentagono, spingono fortemente lo studio di modelli che permettano di minimizzare fortemente la presenza di errori all'interno dei software.

L'ingegneria del software racchiude questi e molti altri elementi creando una scienza che si preoccupa effettivamente di concretizzare come permettere non più ad una singola persona ma ad un team di tanti sviluppatori, di realizzare un ''buon'' software.

Vengono identificati differenti [[ciclo di vita del software]] ovvero diversi processi che possono essere attualizzati da team per giungere ad un risultato comune. Ognuno di questi differenti processi identifica una serie di passi chiave da seguire per realizzare un prodotto sofware secondo uno stile di realizzazione differente per raggiungere differenti obiettivi.

== Metodi di analisi ==

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

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).

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.

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.

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.

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]].

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.

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.

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.

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

==Descrizione==

=== Ciclo di vita a cascata ===

=== Concetti base ===

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''.

{{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".

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]].

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.

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

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

[[Immagine:ciclo_di_vita_a_cascata.gif]]

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

* Analisi di business e analisi dei requisiti;

da cui il richiamo alla cascata che troviamo nel nome.

* 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>

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).

=== Produzione software nel terzo millennio ===

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

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

* '''ANALISI''':

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.

**''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

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).

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''').

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

* assegnare a ciascuna fase la soluzione di problematiche specifiche

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

== Ordinamento universitario ==

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.

=== In Italia ===

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.

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]].

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.

== Note ==

=== Ciclo di vita a spirale ===

<references/>

== Bibliografia ==

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.

* {{cita libro

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.

|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

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.

|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 ==

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).

{{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 ==

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.

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

== Collegamenti esterni ==

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.

* {{Collegamenti esterni}}

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

{{Ingegneria}}

[[Categoria:Teorie dell'informatica]]

{{controllo di autorità}}

{{portale|informatica|ingegneria}}

[[Categoria:Ingegneria del software| ]]

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

[[de:Softwaretechnik]]

[[en:Software engineering]]

[[es:Ingeniería de 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;]]