Ingegneria del software: differenze tra le versioni

Versione delle 10:00, 17 dic 2004

Versione delle 11:18, 19 dic 2004

Riga 6:

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

A grandi linee tutte queste metodologie suddividono il [[ciclo di vita]] in 5 macro ''attività'' ben distinte e successive: [[analisi dei requisiti]], [[pregettoprogetto]] ([[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.

In generale durante l’[[analisi dei requisiti]] si ''formalizzacerca ildi problemacapire 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 funzinoe 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]].

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.

Riga 52:

=== Ciclo di vita a spirale ===

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.

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.

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.

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

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.

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.

[[Categoria:Informatica]]