La crisi dei software\Software crisis

Il software crisis è un termine usato nei primi giorni dell’ingegneria del software per descrivere l’impatto della rapida crescita della potenza degli elaboratori e la complessità dei problemi che dovevano essere affrontati. Le parole chiave della software crisis erano complessità, attese e cambiamento.

I requisiti, continuamente in conflitto tra loro, impedivano lo sviluppo del software. Per esempio, mentre gli utenti domandavano un largo numero di funzionalità, i committenti, generalmente, chiedevano di minimizzare i costi dello sviluppo ed i tempi.

Il concetto di software crisis era emerso alla fine del 1960. Un vecchio uso del termine era in ACM Turing Award Lecture, “The Humble Programmer” (EWD340), di Edsger Dijkstra del 1972 pubblicato in Communications of the ACM.

Dijkstra affermava: “The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem” Edsger Dijkstra: The Humble Programmer (PDF, 473Kb).

Le cause della software crisis era collegate alla complessità dei processi software ed alla relativa immaturità dell’ingegneria del software. La crisi si manifestava in diversi modi:

• Progetti oltre il budget
• Progetti oltre i limiti di tempo
• Software di scarsa qualità
• Software che spesso non rispettava i requisiti
• Progetti ingestibili e codice difficile da manutenere

La crisi del software condusse, quindi, alla nascita dell’Ingegneria del software ed ai primi modelli, come il modello a cascata.

Per superare la crisi, infatti, si dovettero introdurre:

Management

Organizzazione

Teorie e Tecniche

Strumenti

Metodologie

                                                                    – Wikipedia, l’enciclopedia libera.

———————————————————————————————————————————-

Il termine “crisi del software” è stato coniato nei primi anni ’70, quando l’ingegneria del software era praticamente inesistente. Il termine esprime le difficoltà di sviluppo software nel soddisfare la rapida crescita della domanda di software, la complessità dei problemi da risolvere e l’assenza di tecniche consolidate per sviluppare sistemi che funzionano correttamente o che possono essere convalidate.

La percezione che questa crisi è stato avviato a metà degli anni ’60. Uno dei primi riferimenti alla parola, e più in particolare, è stata fatta da EWDijkstra, nel suo discorso durante il Turing Award nel 1972.

In questo lavoro prenderemo in considerazione che questa crisi si è verificato, e qual è stato il percorso intrapreso per risolvere o minimizzare i loro effetti in qualche modo.

Le cause della crisi del software:

Durante la fine degli anni ’50 primi anni ’60 i, la potenza di calcolo delle macchine era piuttosto limitata. Questo è il motivo per programmi che sono stati sviluppati erano “semplici” dal nostro punto di vista. A seguire un processo di sviluppo piuttosto tradizionale, non una metodologia o una via da seguire per lo sviluppo. Questo tempo viene utilizzato per utilizzare i linguaggi di basso livello per lo sviluppo software.

Ma negli anni ’60, il potere delle macchine hanno cominciato ad aumentare in modo significativo. Lingue cominciarono ad apparire programmazione ad alto livello, e le macchine necessarie programmi molto più complessi elaborati fino a quel momento. In breve, è stato un salto enorme in termini di potenziale di hardware, che non è stato accompagnato da un salto nello sviluppo del software.

In questo momento, hanno cominciato a concepire il software come prodotto, e hanno cominciato a sviluppare alcuni progetti che hanno lavorato sulle macchine del tempo.Ma i problemi principali apparsi: i prodotti hanno superato la stima dei costi era ritardi nelle consegne, i benefici non sono stati richiesti, la manutenzione è diventato estremamente difficile e talvolta impossibile, le modifiche erano proibitivi … insomma, è un software sviluppato scarsa qualità, dal momento che la tecnica utilizzata per sviluppare piccoli programmi per macchine con meno potenziale è stata superata, e spesso questo software aveva dimenticato. A titolo di esempio, si può vedere il grafico del 1979, che riflette l’investimento nello sviluppo di software di sistema che l’anno ($ 6,8 milioni), e come il software chiuso

Fonte: Note di gestione Software Engineering. “Tema 1: Software e Ingegneria del Software”

Una delle principali cause di questo, se non l’obiettivo principale è stato dato al processo di sviluppo del software, che era male e, a volte era inesistente. In questo processo, solo ¼ del tempo di sviluppo è stata dedicata alle fasi di analisi, progettazione, codifica e test, e più di ¾ del tempo è stato dedicato alla correzione e manutenzione. Chiaramente dom ¼ dedicare tempo alle prime fasi, eseguire la scansione errori, soprattutto dalla fase di analisi e progettazione, che ha notevolmente ostacolato la realizzazione, la produzione si ferma e inverte costanti di rivedere l’analisi / design.

Per darci, idea tutta fasi di analisi e progettazione di copertura 8% del tempo totale di sviluppo software. Inoltre circa il 80% di errori avvenuto in due fasi, per cui il costo è aumentato correzione di errore secondo evoluto fasi così bestiali. Con questi indicatori era chiaro che qualcosa stava fallendo e che il processo di sviluppo del software aveva bisogno di un cambiamento radicale.

                                                                         -http://histinf.blogs.upv.es/2011/01/04/la-crisis-del-software/