Il concetto di ciclo di vita del software. Ciclo di vita dei sistemi software

Annotazione.

Introduzione.

1. Ciclo di vita del software

Introduzione.

Passaggi del processo di programmazione Riley

Introduzione.

1.1.1. Formulazione del problema.

1.1.2. Progettazione della soluzione.

1.1.3. Codifica degli algoritmi.

1.1.4. Supporto al programma.

1.1.5. Documentazione del software.

Conclusione alla clausola 1.1

1.2. Determinazione della LCPO secondo Lehman.

Introduzione.

1.2.1 Definizione del sistema.

1.2.2. Implementazione.

1.2.3. Servizio.

Conclusione alla clausola 1.2.

1.3. Fasi e lavoro della LCPO secondo Boehm

1.3.1. Modello a cascata.

1.3.2. Giustificazione economica del modello a cascata.

1.3.3. Miglioramento del modello a cascata.

1.3.4. Determinazione delle fasi del ciclo di vita.

1.3.5. Lavoro principale sul progetto.

Letteratura.

introduzione

L'uso industriale dei computer e la crescente domanda di programmi hanno posto sfide urgenti e destinate ad aumentare in modo significativo produttività dello sviluppo software, sviluppo di metodi industriali di pianificazione e progettazione di programmi, trasferimento di tecniche, modelli e metodi organizzativi, tecnici, tecnici, economici e socio-psicologici dalla sfera della produzione materiale a quella dell'uso del computer. Un approccio complesso ai processi di sviluppo, funzionamento e manutenzione del software, ha posto una serie di problemi urgenti, la cui soluzione eliminerà i colli di bottiglia nella progettazione del programma, ridurrà i tempi di completamento del lavoro, migliorerà la selezione e l'adattamento dei programmi esistenti e forse determinerà il destino dei sistemi con computer integrati.

Nella pratica dello sviluppo di progetti software di grandi dimensioni, spesso non esiste approccio unificato alla valutazione dei costi del lavoro, delle scadenze di lavoro e dei costi dei materiali, che ostacola l’aumento della produttività dello sviluppo del software e, in definitiva, la gestione efficace del ciclo di vita del software. Poiché un programma di qualsiasi tipo diventa un prodotto (ad eccezione, forse, di programmi educativi e prototipi), l'approccio alla sua produzione dovrebbe essere in molti modi simile all'approccio alla produzione di prodotti industriali e le questioni di progettazione del programma diventano estremamente importanti. Questa idea è al centro del libro di B.W. Boehm "Ingegneria del software", che abbiamo utilizzato durante la scrittura di questo corso. In questo libro, la progettazione del software si riferisce al processo di creazione di un progetto per un prodotto software.

1 Ciclo di vita del software

INTRODUZIONE

LCPO è un processo continuo che inizia dal momento in cui viene presa la decisione sulla necessità di creare software e termina nel momento in cui viene completamente rimosso dal servizio.

Esistono diversi approcci per determinare le fasi e le attività del ciclo di vita del software (SLC), le fasi del processo di programmazione, i modelli a cascata e a spirale. Ma tutti contengono componenti fondamentali comuni: dichiarazione del problema, progettazione della soluzione, implementazione, manutenzione.

La più famosa e completa, forse, è la struttura del processo del ciclo di vita secondo Boehm, che comprende otto fasi. Verrà presentato più dettagliatamente in futuro.

Una delle opzioni possibili potrebbe essere una descrizione di primo livello secondo Lehman, che comprende tre fasi principali e rappresenta una descrizione del ciclo di vita nel caso più generale.

E, per varietà, presentiamo le fasi del processo di programmazione presentato da D. Riley nel libro “Using the Modula-2 Language”. Questa idea, secondo me, è molto semplice e familiare, e cominciamo con essa.

1.1 Fasi nel processo di programmazione Riley

introduzione

Il processo di programmazione prevede quattro fasi (Figura 1):

formulazione del problema, ad es. ottenere un'adeguata comprensione del compito che il programma dovrebbe svolgere;

progettare una soluzione ad un problema già posto (in generale, tale soluzione è meno formale del programma finale);

codifica del programma, ovvero traduzione della soluzione progettata in un programma eseguibile su una macchina;

supporto al programma, ad es. il processo in corso di risoluzione dei problemi nel programma e di aggiunta di nuove funzionalità.

Riso. 1.Quattro passaggi di programmazione.

La programmazione inizia dal momento in cui utente, cioè. qualcuno che ha bisogno di un programma per risolvere un problema dichiara il problema analista di sistema. L'utente e l'analista di sistema definiscono congiuntamente la dichiarazione del problema. Quest'ultimo viene poi trasmesso algoritmista, che è responsabile della progettazione della soluzione. Una soluzione (o algoritmo) rappresenta una sequenza di operazioni, la cui esecuzione porta alla soluzione di un problema. Poiché spesso l'algoritmo non è adatto per essere eseguito su una macchina, dovrebbe essere tradotto in un programma macchina. Questa operazione viene eseguita dall'encoder. Il manutentore è responsabile delle successive modifiche al programma. programmatore. E l'analista di sistema, l'algoritmista, il codificatore e il programmatore di accompagnamento: sono tutti programmatori.

Nel caso di un progetto software di grandi dimensioni, il numero di utenti, analisti di sistema e algoritmisti può essere significativo. Inoltre, potrebbe essere necessario tornare ai passaggi precedenti a causa di circostanze impreviste. Tutto ciò serve come argomento aggiuntivo per un'attenta progettazione del software: i risultati di ogni passaggio dovrebbero essere completi, accurati e comprensibili.

1.1.1 Dichiarazione del problema

Uno dei passaggi più importanti nella programmazione è la definizione del problema. Funziona come un contratto tra l'utente e il/i programmatore/i. Come un contratto legalmente redatto male, una dichiarazione del problema scritta male è inutile. Con una buona formulazione del problema, sia l'utente che il programmatore rappresentano in modo chiaro e inequivocabile il compito che deve essere eseguito, ad es. in questo caso vengono presi in considerazione sia gli interessi dell'utente che quelli del programmatore. L'utente può pianificare l'utilizzo di software non ancora creato, in base alla conoscenza di ciò che può fare. Una buona esposizione del problema serve come base per formulare la sua soluzione.

Formulazione del problema (specifica del programma); significa essenzialmente una descrizione accurata, completa e comprensibile di ciò che accade quando viene eseguito un programma specifico. L'utente di solito guarda il computer come una scatola nera: per lui non importa come funziona il computer, ma ciò che è importante è ciò che il computer può fare che interessa all'utente. In questo caso l'attenzione principale è focalizzata sull'interazione dell'uomo con la macchina.

Caratteristiche di una buona dichiarazione di problema:

Precisione, cioè. eliminando ogni ambiguità. Non dovrebbero esserci dubbi su quale sarà l'output del programma per ogni dato input.

Completezza, cioè. considerare tutte le opzioni per un dato input, compresi input errati o non intenzionali, e determinare l'output appropriato.

Chiarezza, cioè. deve essere comprensibile sia all'utente che all'analista di sistema, poiché la dichiarazione del problema è l'unico contratto tra loro.

Spesso i requisiti di accuratezza, completezza e chiarezza sono in conflitto. Pertanto, molti documenti legali sono difficili da comprendere perché scritti in un linguaggio formale, che consente di formulare alcune disposizioni con estrema precisione, escludendo eventuali piccole discrepanze. Ad esempio, alcune domande nei documenti d'esame sono talvolta formulate in modo così preciso che lo studente dedica più tempo a comprendere la domanda che a rispondervi. Inoltre, lo studente potrebbe non cogliere nemmeno il significato principale della domanda a causa dell'elevato numero di dettagli. La migliore formulazione del problema è quella che raggiunge un equilibrio tra tutti e tre i requisiti.

Forma standard di dichiarazione del problema.

Considera la seguente dichiarazione del problema: "Inserisci tre numeri ed emetti i numeri in ordine".

Tale affermazione non soddisfa i requisiti di cui sopra: non è né accurata, né completa, né comprensibile. In effetti, i numeri dovrebbero essere inseriti uno per riga o tutti i numeri su una riga? L'espressione "in ordine" significa ordinare dal più grande al meno, dal meno al più grande, oppure lo stesso ordine in cui sono stati introdotti.

Ovviamente una simile affermazione non risponde a molte domande. Se prendiamo in considerazione le risposte a tutte le domande, l'enunciazione del problema diventerà prolissa e difficile da comprendere. Pertanto, D. Riley suggerisce di utilizzare un modulo standard per impostare il problema, che garantisca la massima accuratezza, completezza, chiarezza e comprenda:

nome dell'attività (definizione schematica);

descrizione generale (breve riassunto del compito);

errori (le opzioni di input insolite sono esplicitamente elencate per mostrare a utenti e programmatori quali azioni intraprenderebbe la macchina in tali situazioni);

esempio (un buon esempio può trasmettere l'essenza del problema e anche illustrare casi diversi).

Esempio. Enunciazione del problema in una forma standard.

NOME

Ordinamento di tre numeri interi.

DESCRIZIONE

Input e output di tre numeri interi, ordinati dal numero più piccolo a quello più grande.

Vengono immessi tre numeri interi, un numero per riga. Un numero intero è una o più cifre decimali consecutive, che possono essere precedute da un segno più “+” o da un segno meno “–”.

Vengono stampati i tre numeri interi immessi, tutti e tre stampati sulla stessa riga. I numeri adiacenti sono separati da uno spazio. I numeri vengono visualizzati dal più piccolo al più grande, da sinistra a destra.

1) Se vengono immessi meno di tre numeri, il programma attende un ulteriore input.

2) Le righe di ingresso diverse dalle prime tre vengono ignorate.

Ciclo vitaleè un modello per la creazione e l'utilizzo di un sistema software. Riflette i vari stati di un sistema software, a partire dal momento in cui sorge la necessità di questo sistema software e viene presa la decisione di crearlo, fino al completo ritiro del sistema software dal funzionamento.

Lo standard internazionale ISOIES 12207 definisce un quadro del ciclo di vita contenente i processi, le attività e i compiti che devono essere eseguiti durante la creazione del software. Secondo questo standard, il ciclo di vita del software si basa su tre gruppi di processi:

i principali processi del ciclo di vita, ovvero acquisizione, consegna, sviluppo, esercizio e manutenzione;

processi ausiliari che garantiscono l'attuazione dei processi principali, ovvero documentazione, verifica, certificazione, valutazione della qualità e altri;

processi organizzativi, ovvero gestione del progetto, creazione di infrastrutture di progetto e formazione.

Lo sviluppo include tutto il lavoro volto a creare software in conformità con i requisiti specificati. Ciò include la preparazione della documentazione progettuale e operativa, la preparazione dei materiali necessari per testare la funzionalità e la qualità dei prodotti software.

Fasi principali del processo di sviluppo:

analisi delle esigenze del cliente;

progetto;

implementazione (programmazione).

Il processo operativo comprende il lavoro sulla messa in funzione del software, compresa la configurazione delle postazioni di lavoro, la formazione del personale, la localizzazione dei problemi operativi e l'eliminazione delle cause del loro verificarsi, la modifica del software nell'ambito delle normative stabilite e la preparazione di proposte per la modernizzazione del sistema.

Ogni processo è caratterizzato da determinati compiti e metodi per risolverli, nonché da dati e risultati iniziali.

Il ciclo di vita del software è, di regola, di natura iterativa, cioè vengono implementate fasi, a partire dalle prime, che si ripetono ciclicamente in base alle mutevoli esigenze delle condizioni esterne e all'introduzione di restrizioni.

Modelli del ciclo di vita del software

Esistono diversi modelli del ciclo di vita che determinano l'ordine di esecuzione delle fasi di sviluppo e i criteri per la transizione da una fase all'altra. Ad oggi, due modelli di ciclo di vita sono diventati più diffusi: cascata E spirale.

Nei sistemi informativi omogenei esistenti in precedenza, ogni applicazione era un tutto unico. Per sviluppare tali applicazioni è stato utilizzato un modello del ciclo di vita a cascata, chiamato anche classico O cascata.

Quando si utilizzava il modello a cascata, lo sviluppo veniva visto come una sequenza di fasi, con la transizione alla fase successiva inferiore che si verificava solo dopo che tutto il lavoro nella fase corrente era stato completamente completato. Ciò implica che nel modello a cascata lo sviluppo inizia a livello di sistema e procede attraverso l'analisi, la progettazione, la codifica, il test e la manutenzione.

Figura 1 – Fasi principali dello sviluppo di un modello a cascata

1. L'analisi del sistema specifica il ruolo di ciascun elemento in un sistema informatico e l'interazione degli elementi tra loro. Poiché il software è considerato parte di un sistema più ampio, l'analisi inizia con la determinazione dei requisiti per tutti gli elementi del sistema. La necessità di analisi del sistema si manifesta chiaramente quando si forma l'interfaccia del software con altri elementi, ad es. con hardware o database. Nella stessa fase inizia la soluzione dei problemi di pianificazione del progetto. Durante la pianificazione del progetto, vengono determinati il volume del lavoro del progetto e il suo rischio, i costi di manodopera richiesti, vengono formate le attività lavorative e un programma di lavoro.

L'analisi dei requisiti si riferisce a un singolo elemento software. In questa fase vengono chiarite e dettagliate le funzioni di ciascun elemento, le sue caratteristiche e l'interfaccia. Nella stessa fase, la soluzione al problema della pianificazione del progetto è completata.

2. La progettazione consiste nel creare:

architetture software;

struttura software modulare;

struttura algoritmica del software;

strutture dati;

interfaccia di input/output (moduli di dati di input/output).

Quando si risolvono i problemi di progettazione, l'attenzione principale è rivolta alla qualità del futuro prodotto software.

3. La codifica o lo sviluppo consiste nel tradurre i risultati della progettazione in codice di programma.

4. Il test è l'esecuzione di un programma per identificare difetti nelle funzioni, nella logica e nella forma di implementazione di un prodotto software.

5. La manutenzione consiste nell'effettuare modifiche al software operativo al fine di:

correzioni di bug;

adattamento ai cambiamenti dell'ambiente esterno al software;

miglioramento del software in base alle esigenze del cliente.

Vantaggi dell'utilizzo del modello a cascata:

fornisce un piano e un cronoprogramma per tutte le fasi del progetto, ottimizzando così l'avanzamento dello sviluppo;

in ogni fase viene generato un set completo di documentazione di progettazione, di cui viene verificata la completezza e la coerenza;

le fasi di lavoro eseguite in sequenza logica consentono di pianificare i tempi di completamento di tutti i lavori ed i relativi costi.

Il modello a cascata si è dimostrato efficace nella costruzione di sistemi informativi, per i quali all'inizio dello sviluppo è possibile formulare in modo abbastanza accurato tutti i requisiti del sistema, ad esempio sistemi di calcolo complessi, vari sistemi in tempo reale, ecc. .

Svantaggi del modello a cascata:

i progetti reali spesso richiedono deviazioni dalla sequenza standard di passaggi;

il modello a cascata si basa sulla precisa formulazione dei requisiti software iniziali, ma in realtà, in alcuni casi, all’inizio del progetto, i requisiti del cliente sono determinati solo parzialmente;

i risultati del progetto sono a disposizione del cliente solo dopo il completamento di tutti i lavori.

A causa della necessità nel processo di creazione del software di tornare costantemente alle fasi precedenti e chiarire o rivedere le decisioni prese in precedenza, il vero processo di sviluppo del software basato sul modello a cascata può essere rappresentato dal seguente diagramma (Fig. 2).

Figura 2 – Processo di sviluppo software basato sul modello a cascata

Standard del ciclo di vita del software

GOST 34.601-90
ISO/IEC 12207:1995 (equivalente russo - GOST R ISO/IEC 12207-99)

Metodologie di sviluppo software

Processo Razionale Unificato (RUP).
Microsoft Solutions Framework (MSF). Comprende 4 fasi: analisi, progettazione, sviluppo, stabilizzazione, prevede l'utilizzo della modellazione orientata agli oggetti.
Programmazione estrema ( Programmazione estrema, XP). La metodologia si basa sul lavoro di squadra e sulla comunicazione efficace tra il cliente e l'appaltatore durante l'intero progetto di sviluppo della proprietà intellettuale. Lo sviluppo viene effettuato utilizzando prototipi successivamente perfezionati.

Norma GOST 34.601-90

Lo standard GOST 34.601-90 prevede le seguenti fasi e fasi della creazione di un sistema automatizzato:

Formazione dei requisiti per gli oratori
1. Ispezione dell'impianto e giustificazione della necessità di creare una centrale nucleare
2. Formazione dei requisiti utente per i relatori
3. Preparazione di una relazione sul completamento dei lavori e una domanda per lo sviluppo di una centrale nucleare
Sviluppo del concetto di AC
1. Studiare l'oggetto
2. Svolgere il lavoro di ricerca necessario
3. Sviluppo di opzioni di concetto AC e selezione di un'opzione di concetto AC che soddisfi i requisiti dell'utente
4. Redazione di una relazione sul lavoro svolto
Compito tecnico
1. Sviluppo e approvazione delle specifiche tecniche per la realizzazione di centrali nucleari
Progetto preliminare
1. Sviluppo di soluzioni progettuali preliminari del sistema e delle sue parti
Progetto tecnico
1. Sviluppo di soluzioni progettuali per il sistema e le sue parti
2. Sviluppo della documentazione per il sistema di altoparlanti e le sue parti
3. Sviluppo ed esecuzione della documentazione per la fornitura di componenti
4. Sviluppo di attività di progettazione in parti adiacenti del progetto
Documentazione di lavoro
1. Sviluppo della documentazione di lavoro per la centrale nucleare e le sue parti
2. Sviluppo e adattamento dei programmi
La messa in produzione
1. Preparazione di un oggetto di automazione
2. Formazione del personale
3. Set completo di altoparlanti con prodotti a corredo (software e hardware, sistemi software e hardware, prodotti informativi)
4. Lavori di costruzione e installazione
5. Lavori di messa in servizio
6. Esecuzione di prove preliminari
7. Conduzione dell'operazione di prova
8. Esecuzione di test di accettazione
Supporto CA.
1. Esecuzione dei lavori in conformità agli obblighi di garanzia
2. Servizio post-garanzia

Schizzo, disegni tecnici e documentazione esecutiva sono la costruzione coerente di soluzioni progettuali sempre più accurate. È possibile escludere la fase di "Progettazione di schizzo" e le singole fasi di lavoro in tutte le fasi, combinare le fasi di "Progettazione tecnica" e "Documentazione di lavoro" in una "Progettazione tecnica dettagliata", per eseguire varie fasi e lavorare in parallelo e per includerne di aggiuntivi.

Questo standard non è del tutto adatto agli sviluppi attuali: molti processi non sono sufficientemente rispecchiati e alcune disposizioni sono obsolete.

Norma ISO/IEC 12207/ e sua applicazione

Lo standard ISO/IEC 12207:1995 “Information Technology - Software Life Cycle Processes” è il principale documento normativo che regola la composizione dei processi del ciclo di vita del software. Definisce una struttura del ciclo di vita contenente i processi, le attività e i compiti che devono essere completati durante la creazione del software.

Ogni processo è diviso in una serie di azioni, ogni azione in una serie di compiti. Ogni processo, attività o compito viene avviato ed eseguito da un altro processo secondo necessità e non esistono sequenze di esecuzione predeterminate. Le connessioni tra i dati di input vengono preservate.

Processi del ciclo di vita del software

Di base:
- Acquisizione (azioni e compiti del cliente che acquista il software)
- Consegna (azioni e compiti del fornitore che fornisce al cliente un prodotto o servizio software)
- Sviluppo (azioni e compiti svolti dallo sviluppatore: creazione del software, progettazione e documentazione operativa, preparazione di materiali di test e formazione, ecc.)
- Funzionamento (azioni e compiti dell'operatore - l'organizzazione che gestisce il sistema)
- Manutenzione (azioni e compiti svolti dall'organizzazione di accompagnamento, ovvero il servizio di supporto). Supporto: apportare modifiche al software al fine di correggere errori, aumentare la produttività o adattarsi a mutate condizioni o requisiti operativi.
Ausiliario
- Documentazione (descrizione formalizzata delle informazioni create durante il ciclo di vita del software)
- Gestione della configurazione (applicazione di procedure amministrative e tecniche durante tutto il ciclo di vita del software per determinare lo stato dei componenti del software e gestirne le modifiche).
- Assicurazione della qualità (fornendo garanzie che il sistema informativo e i suoi processi del ciclo di vita siano conformi ai requisiti specificati e ai piani approvati)
- Verifica (determinare che i prodotti software risultanti da alcune azioni soddisfano pienamente i requisiti o le condizioni imposte dalle azioni precedenti)
- Certificazione (determinazione della completezza della conformità dei requisiti specificati e del sistema creato con il loro scopo funzionale specifico)
- Valutazione congiunta (valutazione dello stato dei lavori sul progetto: controllo della pianificazione e gestione delle risorse, del personale, delle attrezzature, degli strumenti)
- Audit (accertamento del rispetto dei requisiti, dei piani e dei termini contrattuali)
- Risoluzione dei problemi (analisi e risoluzione dei problemi, indipendentemente dalla loro origine o fonte, scoperti durante lo sviluppo, il funzionamento, la manutenzione o altri processi)
Organizzativo
- Controllo (azioni e compiti che possono essere svolti da chiunque ne gestisca i processi)
- Creazione di infrastrutture (selezione e manutenzione di tecnologia, standard e strumenti, selezione e installazione di hardware e software utilizzati per lo sviluppo, il funzionamento o la manutenzione del software)
- Miglioramento (valutazione, misurazione, controllo e miglioramento dei processi del ciclo di vita)
- Formazione (formazione iniziale e successivo sviluppo continuo del personale)

Ogni processo include una serie di azioni. Ad esempio, il processo di acquisizione copre le seguenti attività:

Avvio dell'acquisizione
Preparazione delle proposte di offerta
Preparazione e adeguamento del contratto
Supervisione delle attività dei fornitori
Accettazione e completamento dei lavori

Ogni attività include una serie di compiti. Ad esempio, la preparazione delle proposte di offerta dovrebbe includere:

Formazione dei requisiti di sistema
Generazione di un elenco di prodotti software
Stabilire termini e accordi
Descrizione delle limitazioni tecniche (ambiente operativo del sistema, ecc.)

Fasi del ciclo di vita del software, relazioni tra processi e fasi

Modello del ciclo di vita del software- una struttura che determina la sequenza di esecuzione e le relazioni tra processi, azioni e compiti durante tutto il ciclo di vita. Il modello del ciclo di vita dipende dalle specificità, dalla scala e dalla complessità del progetto e dalle condizioni specifiche in cui il sistema viene creato e opera.

Lo standard GOST R ISO/IEC 12207-99 non offre un modello di ciclo di vita specifico. Le sue disposizioni sono comuni a tutti i modelli, metodi e tecnologie del ciclo di vita per la creazione di proprietà intellettuale. Descrive la struttura dei processi del ciclo di vita senza specificare come implementare o completare le attività e i compiti inclusi in tali processi.

Il modello del ciclo di vita del software include:

Fasi;
Risultati del lavoro in ogni fase;
Gli eventi chiave sono punti di completamento del lavoro e del processo decisionale.

Palcoscenico- parte del processo di creazione del software, limitato da un certo periodo di tempo e che termina con il rilascio di un prodotto specifico (modelli, componenti software, documentazione), determinato dai requisiti specificati per questa fase.

In ciascuna fase possono essere eseguiti diversi processi definiti nello standard GOST R ISO/IEC 12207-99 e, viceversa, lo stesso processo può essere eseguito in fasi diverse. La relazione tra processi e fasi è determinata anche dal modello del ciclo di vita del software utilizzato.

Modelli del ciclo di vita del software

Un modello del ciclo di vita è una struttura che definisce la sequenza di esecuzione e le relazioni di processi, attività e compiti eseguiti durante tutto il ciclo di vita. Il modello del ciclo di vita dipende dalle specificità del sistema informativo e dalle condizioni specifiche in cui quest'ultimo viene creato e opera

Ad oggi, i principali modelli del ciclo di vita più diffusi sono i seguenti:

Modello del problema;

modello (o sistema) a cascata (70-85);

modello a spirale (presente).

Modello del problema

Quando si sviluppa un sistema "dal basso verso l'alto" dalle singole attività all'intero sistema (modello di attività), un approccio unificato allo sviluppo viene inevitabilmente perso e sorgono problemi quando si collegano i singoli componenti con le informazioni. Di norma, all'aumentare del numero di compiti, aumentano le difficoltà ed è necessario modificare costantemente i programmi e le strutture dei dati esistenti. La velocità di sviluppo del sistema rallenta, il che rallenta lo sviluppo dell'organizzazione stessa. Tuttavia, in alcuni casi questa tecnologia può essere consigliabile:

Estrema urgenza (i problemi vanno risolti in qualche modo; poi tutto dovrà essere rifatto);

Sperimentazione e adattamento del cliente (gli algoritmi non sono chiari, le soluzioni si trovano per tentativi ed errori).

La conclusione generale è che è impossibile creare in questo modo un sistema informativo sufficientemente ampio ed efficace.

Modello a cascata

Modello a cascata Il ciclo vitale è stato proposto nel 1970 da Winston Royce. Prevede l'attuazione sequenziale di tutte le fasi del progetto in un ordine rigorosamente fisso. Il passaggio alla fase successiva significa il completamento completo del lavoro nella fase precedente (Fig. 1). I requisiti determinati nella fase di formazione dei requisiti sono rigorosamente documentati sotto forma di specifiche tecniche e vengono registrati per l'intero sviluppo del progetto. Ogni fase culmina nel rilascio di un set completo di documentazione sufficiente a consentire il proseguimento dello sviluppo da parte di un altro team di sviluppo.

Gli aspetti positivi dell’utilizzo dell’approccio a cascata sono i seguenti:

in ogni fase viene generato un set completo di documentazione progettuale che soddisfa criteri di completezza e coerenza;

le fasi di lavoro svolte in sequenza logica consentono di pianificare i tempi di realizzazione di tutti i lavori ed i relativi costi.

Fasi del progetto secondo il modello a cascata:

Formazione dei requisiti;
Progetto;
Implementazione;
Test;
Implementazione;
Funzionamento e manutenzione.

Riso. 1. Schema di sviluppo a cascata

L'approccio a cascata si è dimostrato efficace nella costruzione di sistemi informativi, per i quali all'inizio dello sviluppo tutti i requisiti possono essere formulati in modo abbastanza accurato e completo per dare agli sviluppatori la libertà di implementarli nel miglior modo possibile dal punto di vista tecnico. visualizzazione. Sistemi di calcolo complessi, sistemi in tempo reale e altre attività simili rientrano in questa categoria. Tuttavia, nel processo di utilizzo di questo approccio, sono stati scoperti alcuni dei suoi difetti, causati principalmente dal fatto che il processo reale di creazione dei sistemi non si adatta mai completamente a uno schema così rigido. Durante il processo di creazione, c'era una costante necessità di tornare alle fasi precedenti e chiarire o rivedere le decisioni prese in precedenza. Di conseguenza, l’effettivo processo di creazione del software ha assunto la seguente forma (Fig. 2):

Riso. 2. Processo di sviluppo software reale utilizzando uno schema a cascata

Lo svantaggio principale dell’approccio a cascata è il notevole ritardo nell’ottenimento dei risultati. Il coordinamento dei risultati con gli utenti viene effettuato solo nei punti pianificati dopo il completamento di ciascuna fase di lavoro, i requisiti per i sistemi informativi vengono “congelati” sotto forma di specifiche tecniche per tutto il tempo della sua creazione; Pertanto, gli utenti possono esprimere i loro commenti solo dopo che il lavoro sul sistema è stato completamente completato. Se i requisiti vengono indicati in modo impreciso o cambiano nel corso di un lungo periodo di sviluppo del software, gli utenti si ritrovano con un sistema che non soddisfa le loro esigenze. I modelli (sia funzionali che informativi) dell'oggetto automatizzato potrebbero diventare obsoleti contemporaneamente alla loro approvazione. L'essenza di un approccio sistematico allo sviluppo dell'IS risiede nella sua scomposizione (scomposizione) in funzioni automatizzate: il sistema è diviso in sottosistemi funzionali, che a loro volta sono divisi in sottofunzioni, suddivisi in compiti e così via. Il processo di partizionamento continua fino a procedure specifiche. Allo stesso tempo, il sistema automatizzato mantiene una visione olistica in cui tutti i componenti sono interconnessi. Pertanto, il principale vantaggio di questo modello è il suo sviluppo sistematico, mentre i suoi principali svantaggi sono la lentezza e i costi.

Modello a spirale

Per superare questi problemi, è stato proposto modello a spirale ciclo di vita (Figura 3), sviluppato a metà degli anni '80 da Barry Boehm. Si basa sulle fasi iniziali del ciclo di vita: analisi e progettazione. In queste fasi viene testata la fattibilità delle soluzioni tecniche attraverso la realizzazione di prototipi.

Prototipo- un componente software operativo che implementa singole funzioni e interfacce esterne. Ogni iterazione corrisponde alla creazione di un frammento o versione del software, in cui vengono chiariti gli obiettivi e le caratteristiche del progetto, viene valutata la qualità dei risultati ottenuti e viene pianificato il lavoro dell'iterazione successiva.

Ogni iterazione rappresenta un ciclo di sviluppo completo, che porta al rilascio di una versione interna o esterna di un prodotto (o di un sottoinsieme del prodotto finale) che viene migliorata di iterazione in iterazione fino a diventare un sistema completo.

Ogni giro della spirale corrisponde alla creazione di un frammento o versione del software, in cui vengono chiariti gli obiettivi e le caratteristiche del progetto, viene determinata la sua qualità e viene pianificato il lavoro del giro successivo della spirale. Pertanto, i dettagli del progetto vengono approfonditi e specificati in modo coerente e, di conseguenza, viene selezionata un'opzione ragionevole, che viene portata all'implementazione.

Lo sviluppo per iterazioni riflette il ciclo a spirale oggettivamente esistente della creazione di un sistema. Il completamento incompleto del lavoro in ciascuna fase consente di passare alla fase successiva senza attendere il completamento completo del lavoro in quella corrente. Con un metodo di sviluppo iterativo, il lavoro mancante può essere completato nell'iterazione successiva. Il compito principale è mostrare agli utenti del sistema un prodotto realizzabile il più rapidamente possibile, attivando così il processo di chiarimento e integrazione dei requisiti.

Il problema principale del ciclo a spirale è determinare il momento della transizione alla fase successiva. Per risolverlo è necessario introdurre vincoli temporali per ciascuna fase del ciclo di vita. La transizione procede come previsto, anche se non tutto il lavoro pianificato viene completato. Il piano viene elaborato sulla base dei dati statistici ottenuti in progetti precedenti e dell'esperienza personale degli sviluppatori.

Figura 3. Modello a spirale del ciclo di vita di un circuito integrato

Un possibile approccio allo sviluppo del software all’interno del modello del ciclo di vita a spirale è la metodologia RAD (Rapid Application Development), che si è recentemente diffusa. Questo termine si riferisce solitamente a un processo di sviluppo software contenente 3 elementi:

un piccolo team di programmatori (da 2 a 10 persone);

programma di produzione breve ma attentamente elaborato (da 2 a 6 mesi);

un ciclo iterativo in cui gli sviluppatori, man mano che l'applicazione inizia a prendere forma, richiedono e implementano nel prodotto i requisiti ricevuti attraverso l'interazione con il cliente.

Il ciclo di vita del software secondo la metodologia RAD è composto da quattro fasi:

fase di definizione e analisi dei requisiti;

fase di progettazione;

fase di implementazione;

fase di implementazione.

Ad ogni iterazione vengono valutati:

rischio di superamento delle scadenze e dei costi del progetto;
la necessità di eseguire un'altra iterazione;
grado di completezza e accuratezza della comprensione dei requisiti di sistema;
fattibilità della conclusione del progetto.

Vantaggi dell’approccio iterativo:

Lo sviluppo iterativo semplifica notevolmente l'apporto di modifiche al progetto quando cambiano i requisiti del cliente.
Quando si utilizza il modello a spirale, i singoli elementi del sistema informativo vengono gradualmente integrati in un unico insieme. Con un approccio iterativo, l'integrazione avviene praticamente ininterrottamente. Poiché l’integrazione inizia con meno elementi, ci sono molti meno problemi durante la sua attuazione (secondo alcune stime, quando si utilizza il modello di sviluppo a cascata, l’integrazione rappresenta fino al 40% di tutti i costi alla fine del progetto).
Lo sviluppo iterativo offre una maggiore flessibilità nella gestione del progetto, consentendo di apportare modifiche tattiche al prodotto in fase di sviluppo.
L'approccio iterativo semplifica il riutilizzo dei componenti (implementa un approccio alla programmazione basato sui componenti). Questo perché è molto più semplice identificare le parti comuni di un progetto quando sono già state parzialmente sviluppate piuttosto che cercare di identificarle all'inizio del progetto. L'analisi del progetto dopo alcune iterazioni iniziali rivela componenti comuni e riutilizzabili che verranno migliorati nelle iterazioni successive.
Il modello a spirale consente un sistema più affidabile e stabile. Questo perché man mano che il sistema si evolve, errori e punti deboli vengono scoperti e corretti ad ogni iterazione. Allo stesso tempo è possibile adattare i parametri critici delle prestazioni, cosa che nel caso di un modello a cascata è possibile solo prima dell'implementazione del sistema.
L'approccio iterativo consente di migliorare il processo di sviluppo: l'analisi effettuata alla fine di ogni iterazione ci consente di valutare cosa deve essere cambiato nell'organizzazione di sviluppo e migliorarlo all'iterazione successiva.

Annotazione.

Introduzione.

1. Ciclo di vita del software

Introduzione.

Passaggi del processo di programmazione Riley

Introduzione.

1.1.1. Formulazione del problema.

1.1.2. Progettazione della soluzione.

1.1.3. Codifica degli algoritmi.

1.1.4. Supporto al programma.

1.1.5. Documentazione del software.

Conclusione alla clausola 1.1

1.2. Determinazione della LCPO secondo Lehman.

Introduzione.

1.2.1 Definizione del sistema.

1.2.2. Implementazione.

1.2.3. Servizio.

Conclusione alla clausola 1.2.

1.3. Fasi e lavoro della LCPO secondo Boehm

1.3.1. Modello a cascata.

1.3.2. Giustificazione economica del modello a cascata.

1.3.3. Miglioramento del modello a cascata.

1.3.4. Determinazione delle fasi del ciclo di vita.

1.3.5. Lavoro principale sul progetto.

Letteratura.

introduzione

1 Ciclo di vita del software

INTRODUZIONE

LCPO è un processo continuo che inizia dal momento in cui viene presa la decisione sulla necessità di creare software e termina nel momento in cui viene completamente rimosso dal servizio.

La più famosa e completa, forse, è la struttura del processo del ciclo di vita secondo Boehm, che comprende otto fasi. Verrà presentato più dettagliatamente in futuro.

Una delle opzioni possibili potrebbe essere una descrizione di primo livello secondo Lehman, che comprende tre fasi principali e rappresenta una descrizione del ciclo di vita nel caso più generale.

1.1 Fasi nel processo di programmazione Riley

Il processo di programmazione prevede quattro fasi (Figura 1):

formulazione del problema, ad es. ottenere un'adeguata comprensione del compito che il programma dovrebbe svolgere;

progettare una soluzione ad un problema già posto (in generale, tale soluzione è meno formale del programma finale);

codifica del programma, ovvero traduzione della soluzione progettata in un programma eseguibile su una macchina;

supporto al programma, ad es. il processo in corso di risoluzione dei problemi nel programma e di aggiunta di nuove funzionalità.

Riso. 1.Quattro passaggi di programmazione.

La programmazione inizia dal momento in cui utente, cioè. qualcuno che ha bisogno di un programma per risolvere un problema dichiara il problema analista di sistema. L'utente e l'analista di sistema definiscono congiuntamente la dichiarazione del problema. Quest'ultimo viene poi trasmesso algoritmista, che è responsabile della progettazione della soluzione. Una soluzione (o algoritmo) rappresenta una sequenza di operazioni, la cui esecuzione porta alla soluzione di un problema. Poiché spesso l'algoritmo non è adatto per essere eseguito su una macchina, dovrebbe essere tradotto in un programma macchina. Questa operazione viene eseguita dall'encoder. Il programmatore accompagnatore è responsabile delle successive modifiche al programma. E l'analista di sistema, l'algoritmista, il codificatore e il programmatore di accompagnamento: sono tutti programmatori.

1.1.1 Dichiarazione del problema

Caratteristiche di una buona dichiarazione di problema:

Precisione, cioè. eliminando ogni ambiguità. Non dovrebbero esserci dubbi su quale sarà l'output del programma per ogni dato input.

Completezza, cioè. considerare tutte le opzioni per un dato input, compresi input errati o non intenzionali, e determinare l'output appropriato.

Chiarezza, cioè. deve essere comprensibile sia all'utente che all'analista di sistema, poiché la dichiarazione del problema è l'unico contratto tra loro.

Forma standard di dichiarazione del problema.

Considera la seguente dichiarazione del problema: "Inserisci tre numeri ed emetti i numeri in ordine".

nome dell'attività (definizione schematica);

descrizione generale (breve riassunto del compito);

errori (le opzioni di input insolite sono esplicitamente elencate per mostrare a utenti e programmatori quali azioni intraprenderebbe la macchina in tali situazioni);

esempio (un buon esempio può trasmettere l'essenza del problema e anche illustrare casi diversi).

Esempio. Enunciazione del problema in una forma standard.

NOME

Ordinamento di tre numeri interi.

DESCRIZIONE

Input e output di tre numeri interi, ordinati dal numero più piccolo a quello più grande.

Vengono immessi tre numeri interi, un numero per riga. Un numero intero è una o più cifre decimali consecutive, che possono essere precedute da un segno più “+” o da un segno meno “–”.

1) Se vengono immessi meno di tre numeri, il programma attende un ulteriore input.

2) Le righe di ingresso diverse dalle prime tre vengono ignorate.

3) Se una qualsiasi delle prime tre righe contiene più di un numero intero, il programma esce e visualizza un messaggio.

ERRORE DI INPUT: è consentito un solo numero intero per riga.

ingresso ® – 3

Questo passaggio della programmazione è il più difficile. In questa fase, la formulazione del problema deve essere trasformata in un algoritmo. Pertanto, il progettista dell'algoritmo deve avere sufficiente esperienza di programmazione e affrontare ogni nuovo problema sulla base di una metodologia di progettazione consolidata. Sfortunatamente, oggigiorno tutti i programmi di grandi dimensioni contengono bug, che portano a progetti sbagliati. Le cattive progettazioni, a loro volta, sono una conseguenza della complessità dei problemi e dell’uso di metodi di progettazione inadeguati. Per evitare errori nei programmi, gli algoritmisti devono utilizzare procedure di progettazione attentamente progettate basate su regole di inferenza.

Esistono due principali modelli di inferenza:

Il primo modello è noto come inferenza deduttiva. Questa forma di pensiero logico è stata immortalata dal famoso detective Sherlock Holmes. La logica deduttiva applica regole generali a casi specifici. Ad esempio, Holmes potrebbe dedurre l'affermazione specifica "Il maggiordomo è un assassino" dalla conoscenza più generale "L'assassino biondo" e "Il maggiordomo è l'unico uomo biondo che può essere sospettato".

Il secondo modello è uscita induttiva, che è l’opposto dell’inferenza deduttiva. La logica induttiva trae conclusioni generali da casi individuali. Ad esempio, l’inferenza induttiva può essere utilizzata per giustificare la conclusione generale “il sole sorge a est” sulla base di molte osservazioni individuali secondo cui il sole è sempre sorto a est.

Questi due processi di inferenza sono − deduzione(dal generale allo specifico) e induzione(da specifico a generale) - sono strettamente correlati ai due metodi di progettazione più utilizzati: "dall'alto al basso" E "giù su". Come la deduzione, la progettazione top-down inizia con un problema di grandi dimensioni che viene suddiviso in sottoproblemi. Ad esempio, il progettista di un nuovo frigorifero-congelatore, sulla base di una serie iniziale di specifiche dell'unità (ovvero, la dichiarazione del problema), deve produrre progetti e specifiche dettagliate per il prodotto finale (ovvero, il progetto).

Se utilizza un metodo di progettazione top-down, allora un singolo problema di progettazione può essere suddiviso in due sottoproblemi più piccoli: (1) progettazione dell'unità di refrigerazione e (2) progettazione del congelatore.

Tuttavia, è possibile utilizzare il metodo di progettazione dal basso verso l'alto e iniziare progettando il compressore di refrigerazione e quindi i tubi di refrigerazione, l'unità o la cella frigorifera. In questo caso, questa scelta imporrà alcune restrizioni all'intero progetto.

Il compito del progettista è quello di creare un algoritmo che faccia da collegamento tra l’enunciato del problema e il programma pronto per l’esecuzione. La verifica dell'algoritmo creato, cioè quanto bene riflette la formulazione del problema, viene effettuata da un analista di sistema. Per questo motivo sia l'analista di sistema che il progettista devono essere in grado di leggere e comprendere l'algoritmo. Ogni algoritmo è scritto in uno pseudo-linguaggio . Gli algoritmi, chiamati anche pseudocodici, non possono essere eseguiti su nessun computer.

Il compito del codificatore è tradurre l'algoritmo in un programma. Per creare un programma completo, accurato e comprensibile, sono necessari metodi appropriati di scrittura dei programmi. Ad esempio, le ricette culinarie sono solitamente scritte in lingue naturali come inglese, francese, russo o giapponese. I programmi sono scritti in linguaggi di programmazione. Attualmente nessuno dei linguaggi naturali può essere utilizzato come linguaggio di programmazione perché troppo complessi per essere “compresi” dalle macchine. A differenza dei linguaggi naturali, i linguaggi di programmazione vengono creati appositamente per rappresentare una soluzione a un problema che può essere eseguita da un computer.

Il programmatore deve assicurarsi che il programma corrisponda allo pseudocodice prima di uscire. Quindi l'analista del sistema, l'algoritmo e, soprattutto, l'utente devono testare e confermare che funzioni correttamente. Fatto questo possiamo supporre che il programma sia pronto per essere trasferito all'utente completo di tutta la documentazione necessaria.

Tuttavia, la programmazione non finisce qui; seguito da passo di accompagnamento. Il fatto è che potrebbero esserci errori nel programma, dovuti o ad un'esposizione inadeguata del problema, oppure al fatto che il progetto non soddisfa l'esposizione del problema o il programma non corrisponde al progetto. Qualunque sia la ragione, l'utente ha il diritto di esigere che il programma venga modificato perché non immaginava che il programma avrebbe funzionato in questo modo. La correzione degli errori è uno dei compiti principali della manutenzione del programma. Un altro compito altrettanto importante della manutenzione del programma è la sua modifica, ovvero l'aggiunta di nuove funzionalità al programma o la modifica di quelle esistenti. L'utente può modificare i requisiti per il funzionamento del programma, il che, a sua volta, comporterà la necessità di riscriverlo. La complessità della manutenzione del programma dipende dal tipo di modifiche che devono essere apportate: nel peggiore dei casi, potrebbe essere necessario riprogettare completamente il programma dalla produzione alla codifica. In genere, viene dedicato più tempo al mantenimento di un programma che alla sua creazione.

L'ultima parte del processo di programmazione è documentazione. Include un'ampia gamma di descrizioni che facilitano il processo di programmazione e arricchiscono il programma risultante. La documentazione continua dovrebbe essere parte integrante di ogni fase di programmazione. Dichiarazione del problema, documenti di progettazione, algoritmi e programmi: tutti questi sono documenti. La documentazione interna inclusa direttamente nel programma facilita la lettura del codice. Lo scopo di un manuale di formazione (un'altra forma di documentazione) è insegnare all'utente come utilizzare un nuovo programma; Il manuale di riferimento fornisce una descrizione dei comandi del software.

Conclusione alla clausola 1.1.

Secondo il modello presentato in questo capitolo, la programmazione può essere suddivisa in quattro fasi: definizione del problema, progettazione delle soluzioni, codifica del programma e mantenimento del programma. Inoltre, il modello include la documentazione del programma come attività che devono essere eseguite durante tutto il processo di programmazione.

Il modello di programmazione è costruito appositamente per risolvere problemi di grandi dimensioni, poiché interessano gli informatici. Tuttavia, nella pratica, è importante utilizzare tecniche ingegneristiche attentamente selezionate per la progettazione del programma, indipendentemente dalla dimensione dei problemi: le competenze acquisite nella risoluzione di problemi più piccoli possono essere rafforzate e implementate con successo nella risoluzione di problemi più grandi.

definizioni;

implementazione;

servizio.

1.2.1 Definizione del sistema

Il processo di creazione del software inizia con la ricerca pratica che porta all'analisi del sistema, il cui compito è determinare i requisiti generali del sistema e dei programmi. Tale analisi dovrebbe, innanzitutto, stabilire bisogni e obiettivi reali e, se possibile, identificare i metodi disponibili per raggiungere l'obiettivo. Se necessario, l'analisi può basarsi su schemi matematici o altri schemi formali. Si ritiene che con qualsiasi approccio l'analisi specificata debba avere una certa struttura ed essere eseguita secondo una certa teoria. L'analisi e il perfezionamento, condotti congiuntamente con analisti e potenziali utenti, dovrebbero portare allo sviluppo di una specifica dei requisiti finali .

Il processo di scrittura di tale specifica è finalizzato all'ottenimento di una specifica tecnica corretta, completa nel senso che riflette i requisiti e coerente con la definizione dell'implementazione. Segue la fase di preparazione delle specifiche progetto, il cui significato è identificare e strutturare i dati, trasformarli e organizzarne il trasferimento. Inoltre, in questa fase è necessario raggiungere, in un certo senso, una distribuzione ottimale delle funzioni del sistema, selezionare un algoritmo e procedure, nonché identificare i componenti del sistema e la relazione tra loro.

Avendo completato progetto possiamo iniziare implementazione sistemi. Tuttavia, nella pratica, le fasi di progettazione e implementazione si sovrappongono. Pertanto, man mano che procede il processo gerarchico di partizionamento, l'analisi di alcuni elementi del sistema può considerarsi sufficientemente completa per procedere all'implementazione, mentre altri elementi necessitano di ulteriori chiarimenti.

Durante il processo di implementazione è necessario stabilire la correttezza del programma. Le procedure moderne sono in gran parte basate su test, sebbene negli ultimi anni sia aumentato l’uso di metodi di controllo strutturale end-to-end e di convalida dei programmi.

In ogni caso, il test attraverso l'esecuzione del programma viene solitamente eseguito dal basso verso l'alto, prima a livello di blocco (modulare o procedurale), quindi a livello funzionale, componente per componente. Man mano che i singoli componenti vengono testati, vengono combinati in un sistema durante il processo di layout, dopodiché inizia il test del sistema. In definitiva, dopo che la qualità del funzionamento del sistema è stata verificata in modo indipendente e i suoi parametri sono stati valutati, questo è considerato pronto per pubblicazione.

1.2.3 Manutenzione

Il processo di manutenzione inizia immediatamente dopo il rilascio del sistema. Gli errori devono essere identificati e corretti. Se un bug impedisce il normale funzionamento dell'utente, il programma difettoso può essere temporaneamente rimosso dal sistema oppure è possibile apportare correzioni temporanee o permanenti ad alcuni o tutti i sistemi in uso. La correzione o la modifica permanente può quindi essere inclusa in una nuova versione del sistema. Per accogliere tutte le modifiche e le loro combinazioni, vengono create più versioni degli elementi del sistema. Il compito principale diventa la gestione della configurazione del sistema. Un ruolo decisivo nella gestione della programmazione spetta ai servizi di supporto che raccolgono e regolano automaticamente tutte le modifiche del sistema.

Conclusione alla clausola 1.2.

Il metasistema all'interno del quale si sviluppa il programma contiene un numero di cicli di feedback significativamente maggiore rispetto a quanto indicato sopra. Molte attività si sovrappongono, si intrecciano in modi complessi e si ripetono sistematicamente. Pertanto, il modello LCPO presentato da Boehm è sufficientemente giustificato.

1.3 Fasi e lavoro dei centri del ciclo di vita secondo Boehm

Il modello a cascata è stato introdotto negli anni '70 -'80. È conveniente per software omogeneo, quando ogni applicazione era un tutt'uno.

Principali caratteristiche del modello:

Il ciclo di vita è suddiviso in fasi (fasi);

Transizione da uno stadio all'altro - solo dopo il completo completamento della fase corrente;

La fase si conclude con il rilascio di un set di documentazione completo, sufficiente affinché il lavoro possa essere completato da un altro team di sviluppo.

Caratteristiche principali modello a cascata il seguente:

completare ogni fase con attività di verifica e validazione, il cui scopo è eliminare il maggior numero possibile di problemi legati allo sviluppo del prodotto;

ripetizioni cicliche delle fasi implementate a partire dalla prima fase possibile.

Fig.2. Modello a cascata di LCPO.

Nel modello a cascata, il completamento con successo di una delle fasi del ciclo di vita significa il raggiungimento del corrispondente obiettivo di programmazione ingegneristica (vedi paragrafo 2.4.). A questi sotto-obiettivi è necessario aggiungerne altri due:

Progettabilità dettagliata– ottenere specifiche complete e verificate, strutture di controllo e dati, connessioni di interfaccia, caratteristiche, algoritmi di base e determinare le condizioni operative di ciascun componente software.

Codificabilità– ottenere un set completo e verificato di componenti del programma.

Principali vantaggi:

Formazione di un set completo di documentazione di progetto al termine del lavoro sul palco. La documentazione risponde a criteri di completezza e completezza;

Capacità di pianificare scadenze e costi. Per una serie di applicazioni software, questo modello è fattibile: questo è per i sistemi per i quali nella fase di analisi è possibile formulare in modo accurato e completo tutti i requisiti. Ad esempio, programmi informatici complessi.

Principali svantaggi:

Tempi lunghi dall'analisi al completamento;

I requisiti software vengono “congelati” sotto forma di specifiche tecniche fino alla fine dello sviluppo.

1.3.2 Giustificazione economica del modello a cascata

Senza approfondire l’analisi economica che B.U. Boehm presta molta attenzione nel libro "Software Engineering", diciamo solo che la giustificazione economica del modello a cascata, incentrato sul raggiungimento sequenziale degli obiettivi, si basa su due premesse principali:

Per ottenere un prodotto software di alta qualità (cioè che soddisfi pienamente tutti gli obiettivi del prodotto software richiesto), è necessario in ogni caso implementare tutti i sotto-obiettivi in ogni fase.

Qualsiasi altro ordinamento dei sotto-obiettivi si traduce nella creazione di un prodotto software di qualità inferiore.

1.3.3 Miglioramento del modello a cascata

Consideriamo uno dei miglioramenti al modello a cascata ideale: lo sviluppo passo passo.

Sviluppo passo dopo passoè un miglioramento del metodo di progettazione iterativo con prototipazione e sviluppo top-down a più livelli. Questo metodo prevede l'aumento incrementale della funzionalità del software durante il processo di sviluppo.

Essendo un modello a cascata avanzato, lo sviluppo incrementale è stato utilizzato con successo per creare prodotti software sia molto grandi che piccoli.

I principali vantaggi dello sviluppo passo passo rispetto allo sviluppo assolutamente iterativo e allo sviluppo top-down livello per livello sono i seguenti:

l'uso di estensioni successive del programma fornisce un modo molto meno costoso di incorporare l'esperienza dell'utente in un prodotto migliorato rispetto al ri-sviluppo;

i miglioramenti delle funzionalità sono molto più facili da testare e sono più utili dei prodotti intermedi nello sviluppo a più livelli.

Il valore dello sviluppo incrementale risiede principalmente nel cambiare la distribuzione del costo del lavoro per il progetto. Una variante del modello a cascata con sviluppo passo-passo è mostrata nella Figura 3.

1.3.4 Definizione delle fasi del ciclo di vita

Di seguito verrà fornita la formulazione degli obiettivi finali di ciascuna fase per il passaggio alla fase successiva. Per lo sviluppo passo-passo, le affermazioni fornite si riferiscono ai confini di fase di ogni fase di espansione.

Iniziare la fase di pianificazione e analisi dei requisiti.(Revisione concettuale completa di LCPE.)

Ottenere un'architettura di sistema approvata e confermata, compresi gli accordi di base sulla distribuzione delle funzioni tra hardware e programmi. Ottenere una comprensione generale approvata e confermata del funzionamento del software, compresi gli accordi di base sulla distribuzione delle funzioni tra la persona e il sistema.

Formazione di un piano generale per il processo del ciclo di vita, definendo le fasi principali, le risorse, le responsabilità, le scadenze e le opere principali.

Completare la fase di pianificazione e analisi dei requisiti. Inizia la fase di progettazione del prodotto.(Revisione completa dei requisiti software).

Formazione di un piano di sviluppo dettagliato: indicatori dettagliati per il completamento delle fasi di sviluppo, piani di allocazione delle risorse, schemi di struttura organizzativa, responsabilità, scadenze, lavori, metodi e prodotti.

Formazione di un piano dettagliato di utilizzo: punti del piano di sviluppo, il cui contenuto è incentrato sulla formazione, il trasferimento dei programmi, l'implementazione, il funzionamento e la manutenzione.

Formazione di un piano dettagliato di debug del prodotto: piano di gestione della configurazione hardware, piano di controllo qualità, piano generale di verifica e conferma.

Specifica dei requisiti software approvati e convalidati: specifiche funzionali, tecniche e di interfaccia che hanno dimostrato di essere complete, coerenti, verificabili e fattibili.

Un accordo di sviluppo approvato (formalmente o informalmente) basato sui punti di cui sopra.

Completare la fase di progettazione del prodotto. Inizia la fase di progettazione dettagliata.(Completamento dell'analisi dei risultati della progettazione del prodotto.)

Sviluppo di una specifica verificata per un progetto di prodotto software:

formazione di una gerarchia di componenti software, interfacce interblocco per dati e controllo;

formazione di strutture dati fisiche e logiche fino al livello dei singoli campi;

sviluppo di un piano per la distribuzione delle risorse informatiche (tempo, memoria, precisione);

verifica della completezza, coerenza, fattibilità e validità dei requisiti.

Individuazione e risoluzione di tutte le contraddizioni dello sviluppo che aumentano il grado di rischio.

Sviluppo di una fase preliminare di integrazione e debugging, di un piano di manuale utente e di test di accettazione.

Completare la fase di progettazione dettagliata. Inizia la fase di codifica e debug offline.(Completamento del controllo del progetto end-to-end o analisi critica blocco per blocco del progetto.)

Specifiche dettagliate verificate di ciascun blocco:

specifica di ciascuna subroutine, nome, scopo, presupposti, dimensioni, sequenza di chiamate, output degli errori, dati di input e output, algoritmi e progettazione logica;

descrizione del database fino al livello dei singoli parametri, simboli e bit;

Verificare la completezza, la coerenza e la conformità con le specifiche di progettazione del sistema e i piani di allocazione delle risorse.

Piano di test di accettazione approvato.

Manuali per l'utente, nonché un piano preliminare di integrazione e debug completato.

Termina la fase di copia e debug. Iniziare la fase di integrazione e debug.(Soddisfa i criteri di debug offline.)

Controllo del funzionamento di tutte le unità non solo per i valori nominali, ma anche per i valori eccezionali e limitanti.

Controlla tutte le opzioni di input e output, inclusi i messaggi di errore.

Esecuzione di tutti gli operatori e di tutti i rami del trasferimento di controllo.

Verifica del rispetto degli standard di programmazione.

Completamento della documentazione blocco per blocco della struttura interna.

Completare la fase di integrazione e test. Inizia la fase di implementazione.(Completamento dell'analisi dei risultati dei test di accettazione.)

Verifica del rispetto del test di accettazione del programma:

verificare la conformità ai requisiti software;

Dimostrazione dell'accettabilità delle caratteristiche prestazionali specificate nelle specifiche in condizioni anomale.

Accettazione dei prodotti software forniti, report, manuali, database, specifiche della struttura interna.

Completa la fase di implementazione. Iniziare la fase di funzionamento e manutenzione.(Revisione completa dell'accettazione del sistema.)

Verifica dei risultati soddisfacenti dei test di accettazione del sistema.

Verificare che i requisiti di sistema siano soddisfacenti.

Controllo della disponibilità alla produzione di software, hardware, strumenti di manutenzione e personale.

Accettazione dei prodotti forniti e inclusi nel sistema: hardware, software, documentazione, strumenti di formazione e manutenzione.

Completamento di tutti i lavori specificati e messa in servizio del sistema.

Completare la fase di funzionamento e manutenzione(per interruzione).

Adempimento di tutti i punti del piano di smantellamento: trasferimento di programmi, documentazione, creazione di un archivio, transizione ad un nuovo sistema.

1.3.5 Principali lavori sul progetto

Analisi dei requisiti.

Design del prodotto.

Programmazione.

Pianificazione del debug.

Verifica e conferma.

Gestione del progetto.

Gestione della configurazione e controllo qualità.

Pertanto, sono stati presi in considerazione tre approcci per determinare il ciclo di vita del software. Secondo me hanno tutti il diritto di esistere, poiché in un modo o nell'altro riflettono la pratica della programmazione. Inoltre, è facile scoprire punti comuni (si imposta un compito - si definisce un sistema - si analizzano i requisiti; manutenzione del programma - manutenzione - funzionamento e manutenzione).

Va tuttavia notato che la definizione di Boehm delle fasi e del lavoro del centro del ciclo di vita è la più giustificata, perché si basa su un approccio più mirato alla programmazione ingegneristica (finalizzato all'ottenimento di un prodotto software di alta qualità e all'implementazione di un processo efficace di sviluppo e manutenzione del software) ed è giustificato economicamente.

Sulla base di questo rapporto, è chiaro quanto sia importante e necessario conoscere le esigenze del mondo moderno quando si crea un prodotto software (prodotto). Quando si elabora un programma per automatizzare qualsiasi sistema, è importante tenere conto del fatto che il mondo moderno è in continua evoluzione, il che significa che il programma deve essere in grado di cambiare.

È anche importante, quando si redige un programma, tenere conto che il programma deve essere accurato; completo nel suo contenuto e adatto a lavorare con problemi piccoli e grandi secondo il suo scopo; chiaro - in modo che l'utente possa lavorarci con calma e senza difficoltà. E anche affinché il programma possa essere facilmente corretto o integrato in qualsiasi momento in base alle mutevoli esigenze del mondo moderno.

Va ricordato che una buona programmazione non significa codificare una soluzione rapida utilizzando una tecnica adatta, ma una procedura ingegneristica attentamente strumentata che produce software completo, accurato e facilmente comprensibile (chiaro).

1. B.U. Boehm, Ingegneria del software. M.: Radio e comunicazioni. 1985.

2. D.Riley. "Utilizzo del linguaggio Modula-2." M.: Mir. 1993.

3. Yu.V. Ivanov “Programmi e loro cicli di vita” (abstract sulla disciplina “Metrologia del software”). 1998.

Ciao, cari residenti di Khabrovsk! Penso che sarà interessante per qualcuno ricordare quali modelli di sviluppo, implementazione e utilizzo del software esistevano in precedenza, quali modelli vengono utilizzati principalmente ora, perché e di cosa si tratta effettivamente. Questo sarà il mio piccolo argomento.

In realtà, di cosa si tratta ciclo di vita del software- una serie di eventi che si verificano con il sistema durante la sua creazione e ulteriore utilizzo. In altre parole, questo è il tempo che va dal momento iniziale della creazione di qualsiasi prodotto software fino alla fine del suo sviluppo e implementazione. Il ciclo di vita del software può essere rappresentato sotto forma di modelli.

Modello del ciclo di vita del software- una struttura contenente processi di azione e compiti svolti durante lo sviluppo, l'uso e la manutenzione di un prodotto software.
Questi modelli possono essere suddivisi in 3 gruppi principali:

Approccio ingegneristico
Tenendo conto delle specificità del compito
Tecnologie moderne di rapido sviluppo

Ora diamo un'occhiata ai modelli esistenti (sottoclassi) e valutiamo i loro vantaggi e svantaggi.

Modello di codifica ed eliminazione degli errori

Un modello del tutto semplice, tipico degli studenti universitari. È secondo questo modello che la maggior parte degli studenti sviluppa, diciamo, il lavoro di laboratorio.
Questo modello ha il seguente algoritmo:

Formulazione del problema
Prestazione
Controllo del risultato
Se necessario, vai al primo punto

Anche modello terribile obsoleto. È tipico degli anni '60 -'70, quindi non presenta praticamente alcun vantaggio rispetto ai seguenti modelli nella nostra recensione, ma gli svantaggi sono evidenti. Appartiene al primo gruppo di modelli.

Modello del ciclo di vita del software Waterfall (waterfall)

L'algoritmo di questo metodo, che mostro nel diagramma, presenta una serie di vantaggi rispetto all'algoritmo del modello precedente, ma presenta anche una serie di significativo carenze.

Vantaggi:

Implementazione sequenziale delle fasi del progetto in un ordine rigorosamente fisso
Permette di valutare la qualità del prodotto in ogni fase

Screpolatura:

Nessun feedback tra le fasi
Non corrisponde alle condizioni reali di sviluppo del prodotto software

Appartiene al primo gruppo di modelli.

Modello a cascata con controllo intermedio (idromassaggio)

Questo modello è quasi equivalente in termini di algoritmo al modello precedente, tuttavia ha connessioni di feedback con ogni fase del ciclo di vita e presenta uno svantaggio molto significativo: Aumento di 10 volte dei costi di sviluppo. Appartiene al primo gruppo di modelli.

Modello V (sviluppo basato sui test)

Questo modello ha un algoritmo più vicino ai metodi moderni, ma presenta ancora una serie di svantaggi. È una delle principali pratiche di programmazione estrema.

Modello basato sullo sviluppo del prototipo

Questo modello si basa sullo sviluppo di prototipi e sulla prototipazione del prodotto.
Prototipazione utilizzati nelle prime fasi del ciclo di vita del software:

Chiarire requisiti poco chiari (prototipo dell'interfaccia utente)
Scegli una delle numerose soluzioni concettuali (implementazione di scenari)
Analizzare la fattibilità del progetto

Classificazione dei prototipi:

Orizzontale e verticale
Usa e getta ed evolutivo
carta e storyboard

Orizzontale prototipi: modella esclusivamente l'interfaccia utente senza influire sulla logica di elaborazione e sul database.
Verticale prototipi - sperimentazione di soluzioni architettoniche.
Monouso prototipi - per un rapido sviluppo.
Evolutivo i prototipi sono la prima approssimazione di un sistema evolutivo.

Il modello appartiene al secondo gruppo.

Modello del ciclo di vita del software a spirale

Il modello a spirale è un processo di sviluppo software che combina progettazione e prototipazione incrementale per unire i vantaggi dei concetti bottom-up e top-down.

Vantaggi:

Ottieni risultati rapidamente
Maggiore competitività
Il cambiamento dei requisiti non è un problema

Screpolatura:

Mancanza di regolamentazione del palco

Il terzo gruppo comprende modelli come programmazione estrema(XP) MISCHIA, modello incrementale(RUP), ma vorrei parlarne in un argomento a parte.

Grazie per la vostra attenzione!