Quindi, l'essenza dell'approccio strutturale allo sviluppo del software EIS risiede nella sua scomposizione (partizionamento) in funzioni automatizzate: il sistema è suddiviso in sottosistemi funzionali, che, a loro volta, sono suddivisi in sottofunzioni, quelli in compiti e così via fino a procedure specifiche. Allo stesso tempo, il sistema mantiene una visione olistica in cui tutti i componenti costitutivi sono interconnessi. Quando si sviluppa un sistema "dal basso verso l'alto", dalle singole attività all'intero sistema, si perde l'integrità, sorgono problemi quando si descrive l'interazione delle informazioni dei singoli componenti.
Tutti i metodi più comuni dell'approccio strutturale si basano su una serie di principi generali:
1. Il principio del "divide et impera";
2. Il principio dell'ordinamento gerarchico - il principio di organizzare le parti costitutive del sistema in strutture gerarchiche ad albero con l'aggiunta di nuovi dettagli a ciascun livello.
La selezione di due principi di base non significa che i restanti principi siano secondari, perché ignorarne qualcuna può portare a conseguenze imprevedibili (incluso il fallimento dell'intero progetto”). I principali di questi principi sono:
1. Il principio di astrazione - evidenziando gli aspetti essenziali del sistema e la distrazione dal non essenziale.
2. Il principio di coerenza, validità e coerenza degli elementi del sistema.
3. Principio strutturante dati - dati dovrebbe essere strutturato e organizzato gerarchicamente.
Nell'approccio strutturale, ci sono fondamentalmente due gruppi di strumenti che descrivono la struttura funzionale del sistema e le relazioni tra i dati. Ogni gruppo di strumenti corrisponde a determinati tipi di modelli (diagrammi), i più comuni tra loro sono:
· DFD (Data Flow Diagrams) - diagrammi dei flussi di dati;
SADT (Structured Analysis and Design Technique - metodologia di analisi strutturale e progettazione) - modelli e corrispondenti diagrammi funzionali: notazioni IDEF0 (modellazione funzionale dei sistemi), IDEF1x (modellazione concettuale di database), IDEF3x (sistemi costruttivi per la valutazione della qualità di un oggetto ; descrizione grafica dei processi di flusso, l'interazione di processi e oggetti che vengono modificati da questi processi);
· ERD (Entity - Relationship Diagrams) - diagrammi "entità-relazione".
In quasi tutti i metodi dell'approccio strutturale (analisi strutturale), nella fase di formazione dei requisiti software vengono utilizzati due gruppi di strumenti di modellazione:
1. Diagrammi che illustrano le funzioni che il sistema deve svolgere e le relazioni tra queste funzioni - DFD o SADT (IDEF0).
2. Diagrammi che modellano i dati e le loro relazioni (ERD).
La forma specifica dei diagrammi elencati e l'interpretazione delle loro costruzioni dipendono dalla fase del ciclo di vita del software.
Nella fase di formazione dei requisiti software, i modelli SADT e DFD vengono utilizzati per costruire il modello "AS-IS" e il modello "TO-BE", riflettendo così la struttura esistente e proposta dei processi aziendali dell'organizzazione e l'interazione tra di essi (utilizzando i modelli SADT come di solito limitati solo a questa fase, poiché non erano originariamente destinati alla progettazione del software). Con l'aiuto di ERD, viene eseguita la descrizione dei dati utilizzati nell'organizzazione a livello concettuale, indipendentemente dai mezzi di implementazione del database (DBMS).
Annotazione: Un approccio flessibile allo sviluppo del software, vengono considerati i principi di base dello sviluppo flessibile. Viene fornito un elenco di tecniche che, in una certa misura, corrispondono ai principi dello sviluppo flessibile del software. Vengono analizzati i valori chiave e i principi dello sviluppo agile.
Puoi scaricare la presentazione di questa conferenza.
Scopo della lezione:
Acquisisci una comprensione dello scopo e dei principi di base dello sviluppo agile del software.
Metodologia di sviluppo software agile focalizzato sull'uso di un approccio iterativo, in cui Software viene creato gradualmente, a piccoli passi, inclusa l'implementazione di un determinato insieme di requisiti. Si presume che i requisiti possano cambiare. I team che utilizzano metodologie agili sono formati da sviluppatori versatili che svolgono varie attività nel processo di creazione di un prodotto software.
Quando si utilizzano metodologie agili, la minimizzazione del rischio viene effettuata riducendo lo sviluppo a una serie di cicli brevi chiamati iterazioni, della durata di 2-3 settimane. Un'iterazione è un insieme di attività programmate per essere completate in un periodo di tempo specifico. In ogni iterazione, viene creata una versione funzionante del sistema software, in cui la massima priorità (per questa iterazione) requisiti del cliente. Ogni iterazione esegue tutte le attività necessarie per creare un software funzionante: pianificazione, analisi dei requisiti, progettazione, codifica, test e documentazione. Mentre una singola iterazione generalmente non è sufficiente per il rilascio nuova versione prodotto, resta inteso che la corrente Software pronto per il rilascio alla fine di ogni iterazione. Alla fine di ogni iterazione, il team ridefinisce le priorità dei requisiti per il prodotto software, eventualmente apportando modifiche allo sviluppo del sistema.
Per la metodologia di sviluppo agile, vengono dichiarati postulati chiave che consentono ai team di raggiungere prestazioni elevate:
Persone e interazione. Le persone sono la parte più importante del successo. I singoli membri del team e una buona comunicazione sono essenziali per i team ad alte prestazioni. Per facilitare la comunicazione, le pratiche agili comportano frequenti discussioni sui risultati del lavoro e modifiche alle decisioni. Le discussioni possono svolgersi quotidianamente per pochi minuti e alla fine di ogni iterazione con un'analisi dei risultati del lavoro e una retrospettiva. Per comunicare in modo efficace durante le riunioni, i membri del team devono rispettare le seguenti regole fondamentali di condotta:
Oltre a un team efficace e buone comunicazioni, sono necessari strumenti software perfetti per creare team ad alte prestazioni con metodologie agili.
Il software funzionante è più importante della documentazione completa. Tutte le metodologie agili evidenziano la necessità di consegnare piccoli pezzi di software funzionante al cliente a intervalli prestabiliti. Software, di norma, deve superare il livello di unit test, test a livello di sistema. La quantità di documentazione dovrebbe essere ridotta al minimo. Durante il processo di progettazione, il team dovrebbe tenere aggiornato un breve documento contenente le motivazioni della decisione e una descrizione della struttura.
La cooperazione con il cliente è più importante degli accordi formali previsti dal contratto. Affinché il progetto possa essere completato con successo, è necessaria una comunicazione regolare e frequente con il cliente. Il cliente deve partecipare regolarmente alla discussione delle decisioni prese sul software, esprimere i propri desideri e commenti. Coinvolgere il cliente nel processo di sviluppo del software è necessario per creare un prodotto di qualità.
Rispondere rapidamente al cambiamento è più importante che seguire un piano. La capacità di rispondere al cambiamento determina in gran parte il successo di un progetto software. Nel processo di creazione di un prodotto software, spesso cambiano requisiti del cliente. I clienti spesso non sanno esattamente cosa vogliono finché non lo vedono funzionare. Software. Si ricercano metodologie agili feedback dai clienti nel processo di creazione di un prodotto software. La reattività al cambiamento è essenziale per creare un prodotto che garantisca la soddisfazione del cliente e il valore aziendale.
I principi dello sviluppo agile sono supportati da 12 principi. Specifiche metodologie agili definiscono processi e regole più o meno conformi a questi principi. Metodologie di creazione flessibili prodotti software si basano sui seguenti principi:
I principi di cui sopra, in una certa misura, corrispondono a una serie di metodologie di sviluppo del software:
| Modellazione agile | un insieme di concetti, principi e tecniche (pratiche) che consentono di eseguire rapidamente e facilmente la modellazione e la documentazione nei progetti di sviluppo software; |
| Processo unificato agile (AUP) | una versione semplificata di IBM RationalUnifiedProcess(RUP), che descrive un'approssimazione (modello) semplice e comprensibile per la creazione di software per applicazioni aziendali; |
| ApriUP | è un metodo iterativo-incrementale di sviluppo del software. Posizionato come opzione RUP leggera e flessibile; |
| AgileDataMethod | un gruppo di metodi iterativi di sviluppo software in cui i requisiti e le soluzioni vengono raggiunti attraverso la collaborazione di diversi team interfunzionali; |
| DSDM | una metodologia per lo sviluppo di sistemi dinamici basata sul concetto di sviluppo rapido di applicazioni (RapidApplicationDevelopment, RAD). Rappresenta un approccio iterativo e incrementale che enfatizza il coinvolgimento continuo dell'utente/consumatore nel processo; |
| Programmazione estrema (XP) | programmazione estrema; |
| Sviluppo software adattivo (ADD) | sviluppo di software adattivo; |
| Sviluppo guidato dalle funzionalità (FDD) | sviluppo incentrato sull'aggiunta graduale di funzionalità; |
| Diventa reale | un approccio iterativo senza specifiche funzionali utilizzato per le applicazioni web; |
| MSFfogAgileSoftwareDevelopment | Metodologia di sviluppo software agile di Microsoft; |
| Mischia | stabilisce le regole per la gestione del processo di sviluppo e consente di utilizzare le pratiche di codifica esistenti regolando i requisiti o apportando modifiche tattiche [ |
Ad oggi, nell'ingegneria del software, ci sono due approcci principali allo sviluppo del software EIS, la cui differenza fondamentale è dovuta a diversi modi decomposizione dei sistemi. Il primo approccio è chiamato funzionale-modulare o strutturale. Si basa sul principio della scomposizione funzionale, in cui la struttura del sistema è descritta in termini di gerarchia delle sue funzioni e trasferimento di informazioni tra i singoli elementi funzionali. Il secondo approccio orientato agli oggetti utilizza la scomposizione degli oggetti. In questo caso, la struttura del sistema è descritta in termini di oggetti e relazioni tra di essi, e il comportamento del sistema è descritto in termini di scambio di messaggi tra oggetti.
Quindi, l'essenza dell'approccio strutturale allo sviluppo del software EIS risiede nella sua scomposizione (partizionamento) in funzioni automatizzate: il sistema è suddiviso in sottosistemi funzionali, che, a loro volta, sono suddivisi in sottofunzioni, quelli in compiti e così via fino a procedure specifiche. Allo stesso tempo, il sistema automatizzato mantiene una visione olistica in cui tutti i componenti sono interconnessi. Quando si sviluppa un sistema "dal basso verso l'alto", dalle singole attività all'intero sistema, si perde l'integrità, sorgono problemi quando si descrive l'interazione delle informazioni dei singoli componenti.
Tutti i metodi più comuni dell'approccio strutturale si basano su una serie di principi generali. I principi di base sono:
il principio del "divide et impera" (cfr. paragrafo 2.1.1);
principio di ordinamento gerarchico - il principio di organizzare le parti costitutive del sistema in strutture gerarchiche ad albero con l'aggiunta di nuovi dettagli a ciascun livello.
La selezione di due principi di base non significa che gli altri principi siano secondari, poiché ignorarne uno può portare a conseguenze imprevedibili (incluso il fallimento dell'intero progetto). I principali di questi principi sono:
il principio di astrazione - l'allocazione degli aspetti essenziali del sistema e la distrazione da quelli non essenziali;
il principio di coerenza - la validità e la coerenza degli elementi del sistema;
il principio della strutturazione dei dati - i dati devono essere strutturati e organizzati gerarchicamente.
L'approccio strutturale utilizza principalmente due gruppi di strumenti che descrivono la struttura funzionale del sistema e le relazioni tra i dati. Ogni gruppo di strumenti corrisponde a determinati tipi di modelli (diagrammi), i più comuni dei quali sono:
DFD (Data Flow Diagrams) - diagrammi di flusso di dati;
SADT (Structured Analysis and Design Technique - un metodo di analisi e progettazione strutturale) - modelli e corrispondenti diagrammi funzionali;
ERD (Entity-Relationship Diagrams) - diagrammi entità-relazione.
I diagrammi di flusso di dati e i diagrammi entità-relazione sono i tipi di modelli più comunemente utilizzati negli strumenti CASE.
La forma specifica dei diagrammi elencati e l'interpretazione delle loro costruzioni dipendono dalla fase del ciclo di vita del software.
Nella fase di formazione dei requisiti per il software, i modelli SADT e DFD vengono utilizzati per costruire il modello "AS-IS" e il modello "TO-BE", riflettendo così la struttura esistente e proposta dei processi aziendali dell'organizzazione e l'interazione tra loro (l'utilizzo dei modelli SADT , di regola, è limitato solo a questa fase, poiché originariamente non erano destinati alla progettazione del software). Con l'aiuto di ERD, la descrizione dei dati utilizzati nell'organizzazione viene eseguita a un livello concettuale indipendente dagli strumenti di implementazione del database (DBMS).
In fase di progettazione, i DFD vengono utilizzati per descrivere la struttura del sistema software progettato, mentre possono essere perfezionati, ampliati e integrati con nuovi progetti. Allo stesso modo, gli ERD vengono perfezionati e integrati con nuovi costrutti che descrivono la rappresentazione dei dati a un livello logico adatto alla successiva generazione di uno schema di database. Questi modelli possono essere integrati con diagrammi che riflettono l'architettura di sistema del software, diagrammi a blocchi dei programmi, la gerarchia delle schermate e dei menu, ecc.
I modelli elencati insieme danno Descrizione completa Software EIS, indipendentemente dal fatto che il sistema sia esistente o di nuova concezione. La composizione dei diagrammi in ciascun caso particolare dipende dalla complessità del sistema e dalla completezza richiesta della sua descrizione.
L'argomento per la maggior parte degli esempi di diagrammi forniti in questo capitolo è il sistema fiscale della Federazione Russa, la cui descrizione più completa è contenuta nel Codice Fiscale della Federazione Russa. Tecnologie dell'informazione utilizzati nel sistema fiscale della Federazione Russa, hanno determinate caratteristiche.
Ora nell'ingegneria del software ci sono due approcci principali allo sviluppo del software IS, la cui differenza fondamentale è dovuta ai diversi modi di scomposizione dei sistemi: un approccio funzionale-modulare (strutturale), che si basa sul principio della scomposizione funzionale, in cui la struttura del sistema è descritta in termini di gerarchia delle sue funzioni e trasferimento di informazioni tra i singoli elementi funzionali, e approccio orientato agli oggetti, che utilizza la scomposizione degli oggetti, descrive la struttura dell'IS in termini di oggetti e relazioni tra loro e il comportamento del sistema in termini di messaggistica tra oggetti.
Quindi, l'essenza dell'approccio strutturale allo sviluppo del software IS risiede nella sua scomposizione in funzioni automatizzate: il sistema è suddiviso in sottosistemi funzionali, che a loro volta sono suddivisi in sottofunzioni, sono suddivisi in compiti e così via fino a specifiche procedure. Allo stesso tempo, IS preserva l'integrità della rappresentazione, dove tutti i componenti sono interconnessi. Quando si sviluppa un sistema "dal basso verso l'alto", dalle singole attività all'intero sistema, si perde l'integrità, sorgono problemi quando si descrive l'interazione delle informazioni dei singoli componenti.
I principi di base dell'approccio strutturale sono:
o principio " divide et impera";
o principio ordinamento gerarchico - il principio di organizzare i sistemi dei componenti in strutture gerarchiche ad albero con l'aggiunta di nuovi dettagli ad ogni livello. La selezione di due principi di base non significa che i restanti principi siano secondari, poiché ignorarne uno può portare a conseguenze imprevedibili.
I principali di questi principi sono:
o astrazione - evidenziare gli aspetti essenziali del sistema;
o consistenza - validità e coerenza degli elementi del sistema;
o strutturazione dei dati - i dati dovrebbero essere strutturati e organizzati gerarchicamente.
Modellazione visiva. Un modello software è generalmente chiamato descrizione formalizzata di un sistema software a un certo livello di astrazione. Ogni modello definisce un aspetto specifico del sistema, utilizza una serie di diagrammi e documenti in un determinato formato e riflette i pensieri e le attività di persone diverse con interessi, ruoli o compiti specifici.
I modelli grafici (visivi) sono strumenti per visualizzare, descrivere, progettare e documentare l'architettura del sistema. La composizione dei modelli utilizzati in ogni progetto specifico, e il grado di dettaglio nel caso generale, dipendono dai seguenti fattori:
o le difficoltà del sistema progettato;
o la necessaria completezza della sua descrizione;
o conoscenze e abilità dei partecipanti al progetto;
o tempo dedicato alla progettazione.
La modellazione visiva ha fortemente influenzato in particolare lo sviluppo degli strumenti CASE. Il concetto di CASE (Computer Aided Software Engineering) è usato in senso lato. Il significato originale di questo concetto, limitato solo ai compiti di automatizzazione dello sviluppo del software, ha ora acquisito un nuovo significato, coprendo la maggior parte dei processi del ciclo di vita del software.
La tecnologia CASE è un insieme di metodi di progettazione del software, nonché un insieme di utensili, consentendo in forma visiva di modellare l'area tematica, analizzare questo modello in tutte le fasi dello sviluppo e della manutenzione del software e sviluppare applicazioni in conformità con le esigenze informative degli utenti. La maggior parte degli strumenti CASE esistenti si basa su metodi di analisi e progettazione strutturali o orientati agli oggetti, utilizzando specifiche sotto forma di diagrammi o testi per descrivere requisiti esterni, relazioni tra modelli di sistema, dinamiche di comportamento del sistema e architetture software.
Nella prima parte si è scelto di confrontare metodologie di sviluppo software quali indicatori come il rapporto tra metodologia e sviluppo iterativo e il grado di formalità nella progettazione dei materiali di lavoro e in generale nello sviluppo. In questa parte, utilizziamo queste metriche per confrontare le pratiche di sviluppo software più note.
Purtroppo, questa è la categoria più difficile da descrivere - dopotutto, include sia il prodotto del lancio convulso di un principiante che cerca di completare il suo primo progetto ad ogni costo, sia metodologie abbastanza mature e consolidate che hanno assorbito molti anni di e variegate esperienze di specifici team di sviluppo e addirittura descritti in regolamenti interni. Poiché le persone che sono in grado di sviluppare la propria metodologia, di norma, possono valutarla in termini di iterazione e formalizzazione, ci concentreremo sui principianti. Purtroppo, molto spesso ciò significa che le regole per condurre lo sviluppo non esistono affatto o sono state sviluppate e adottate, ma non vengono implementate. Naturale in tali condizioni è un livello estremamente basso di formalismo di sviluppo. Quindi è tutto chiaro.
Sviluppo "Come funziona"
Che ne dici di un approccio iterativo? Purtroppo, di norma, non viene utilizzato in tali progetti. Innanzitutto perché consentirebbe già alle prime iterazioni di valutare il progetto come estremamente dubbio e necessitante di un intervento urgente della dirigenza superiore per ristabilire l'ordine. Dopotutto, in un progetto iterativo, la tradizionale risposta del programmatore che tutto è pronto al 90% per lui dura solo fino al completamento della prima iterazione...
Metodologie strutturali
I metodi strutturali sono un gruppo di metodologie sviluppate, di regola, anche prima dell'uso diffuso dei linguaggi orientati agli oggetti. Tutti implicano lo sviluppo a cascata. Anche se, come si è scoperto, in quell'articolo, che viene spesso citato come prima presentazione dell'approccio a cascata, si diceva che era auspicabile avviare il progetto con lo sviluppo di un prototipo, ovvero eseguire almeno due iterazioni.
Tuttavia, la base di queste metodologie è il passaggio sequenziale da un lavoro all'altro e il trasferimento dei risultati (documenti) della fase successiva ai partecipanti di quella successiva.
Inoltre, tutte queste metodologie presuppongono un approccio altamente formalizzato, sebbene in esse si possano trovare affermazioni su una ragionevole quantità di documentazione. Uno degli esempi non ovvi del fatto che le metodologie di sviluppo del software si siano sviluppate non solo in Occidente è una citazione da un libro pubblicato nel nostro paese all'inizio degli anni '80, in cui si afferma che il grado di formalizzazione di un'attività di programmazione dovrebbe essere determinato in base su quanto bene l'analista e il programmatore. E questo nonostante il tema del libro riguardasse lo sviluppo di sistemi abbastanza critici, come vengono ora chiamati, errori in cui portano a gravi perdite o addirittura disastri.
Le metodologie agili si basano su dieci principi, di cui nomineremo solo quelli che determinano la valutazione di tali metodologie in base ai parametri selezionati:
Pertanto, questi metodi sono chiaramente focalizzati sullo sviluppo iterativo del software e sulla formalizzazione minima del processo. Tuttavia, è necessario fare una riserva riguardo al secondo punto: questi metodi sono focalizzati sul livello minimo di formalizzazione accettabile per un determinato progetto. Almeno una delle metodologie incluse nel gruppo flessibile - Crystal - presenta modifiche atte ad eseguire processi con un diverso numero di partecipanti e diversa criticità del software sviluppato (la criticità del software è determinata dalle possibili conseguenze degli errori, che possono variare da insignificanti perdita finanziaria correggere un errore in uno catastrofico). Affinché un ulteriore confronto con metodologie flessibili non sia inutile, presentiamo brevi descrizioni molti di loro.
La metodologia XP, sviluppata da Kent Beck, Ward Cunningham e Ron Jeffries, è oggi la più conosciuta delle metodologie agili. A volte il concetto stesso di "metodologie agili" viene identificato esplicitamente o implicitamente con XP, che predica socialità, semplicità, feedback e coraggio. È descritto come un insieme di pratiche: gioco di pianificazione, rilasci brevi, metafore, design semplice, refactoring del codice, sviluppo test-ahead, programmazione in coppia, condivisione del codice, 40 ore settimana di lavoro, presenza del cliente e standard di codice. L'interesse per XP è cresciuto dal basso verso l'alto, da sviluppatori e tester, tormentati da processi dolorosi, documentazione, metriche e altri formalismi. Non rifiutavano la disciplina, ma non erano disposti a seguire insensatamente i requisiti formali e cercavano nuovi approcci rapidi e flessibili allo sviluppo di programmi di alta qualità.
Nell'utilizzo di XP, l'attenta progettazione preliminare del software è sostituita, da un lato, dalla presenza costante del cliente nel team, pronto a rispondere a qualsiasi domanda e valutare qualsiasi prototipo, e dall'altro, a periodiche revisioni del codice (c.d. refactoring). Il codice accuratamente commentato è considerato la base della documentazione di progettazione. Molta attenzione nella metodologia è data ai test. Di norma, per ogni nuovo metodo viene prima scritto un test, quindi viene sviluppato il codice del metodo effettivo fino a quando il test inizia a funzionare correttamente. Questi test sono archiviati in suite che vengono eseguite automaticamente dopo ogni modifica del codice.
Sebbene la programmazione in coppia e la settimana lavorativa di 40 ore siano forse le caratteristiche più note di XP, sono ancora di natura di supporto e contribuiscono all'elevata produttività degli sviluppatori e alla riduzione degli errori di sviluppo.
Crystal è una famiglia di metodologie che determinano il grado di formalizzazione richiesto del processo di sviluppo, in funzione del numero dei partecipanti e della criticità delle attività.
La metodologia Crystal Clear è inferiore a XP in termini di prestazioni, ma è il più semplice possibile da usare. Richiede uno sforzo minimo per essere implementato perché si concentra sulle abitudini umane. Si ritiene che questa metodologia descriva l'ordine naturale dello sviluppo del software, stabilito in team sufficientemente qualificati, se non sono impegnati nell'implementazione mirata di un'altra metodologia.
Caratteristiche principali di Crystal Clear:
Oltre a Crystal Clear, nella famiglia Crystal esistono diverse altre metodologie progettate per progetti più grandi o più critici. Differiscono in requisiti leggermente più severi per la quantità di documentazione e procedure di supporto, come il controllo delle modifiche e della versione.
Feature Driven Development (FDD) opera in termini di funzionalità di sistema o funzionalità che è abbastanza vicina al concetto di caso d'uso RUP. Forse la differenza più significativa è un'ulteriore restrizione: "ogni funzione deve consentire l'implementazione in non più di due settimane". Cioè, se il caso d'uso è abbastanza piccolo, può essere considerato una funzione, e se è grande, dovrebbe essere suddiviso in diverse funzioni relativamente indipendenti.
FDD include cinque processi, con gli ultimi due ripetuti per ogni caratteristica:
Il lavoro sul progetto prevede build frequenti ed è suddiviso in iterazioni, ciascuna delle quali viene implementata utilizzando uno specifico set di funzionalità.
Gli sviluppatori in FDD sono divisi in "maestri di classe" e "capi programmatori". I principali programmatori coinvolgono i proprietari delle classi coinvolte per lavorare sulla proprietà successiva. Per fare un confronto: in XP non ci sono personalmente responsabili di classi o metodi.
L'elenco delle metodologie flessibili è attualmente piuttosto ampio. Tuttavia, le metodologie che abbiamo descritto danno un quadro molto completo dell'intera famiglia.
Quasi tutte le metodologie agili utilizzano un approccio iterativo, in cui viene pianificata in dettaglio solo una quantità limitata di lavoro associata al rilascio della prossima release.
Quasi tutte le metodologie agili si concentrano sull'approccio più informale allo sviluppo. Se il problema può essere risolto nel corso di una normale conversazione, allora è meglio farlo. Inoltre, è necessario redigere la decisione sotto forma di documento cartaceo o elettronico solo quando è impossibile farne a meno.
Metodologie agili
I GOST, come i requisiti CMM descritti nella sezione successiva, non sono metodologie. Di norma, non descrivono i processi di sviluppo del software stessi, ma formulano solo determinati requisiti per i processi, a cui corrispondono varie metodologie in un modo o nell'altro. Il confronto dei requisiti in base agli stessi criteri con cui confrontiamo le metodologie ti aiuterà a decidere immediatamente quali metodologie dovresti utilizzare se devi sviluppare in conformità con GOST.
Al momento, in Russia sono in vigore i vecchi GOST della 19a e 34a serie e il più recente GOST R ISO IEC 122207. I GOST della 19a e 34a serie sono strettamente focalizzati sull'approccio a cascata allo sviluppo del software. Lo sviluppo in conformità con questi GOST avviene in più fasi, ognuna delle quali prevede l'esecuzione di un lavoro rigorosamente definito e termina con il rilascio di un numero piuttosto elevato di documenti molto formalizzati ed estesi. Pertanto, l'aderenza immediata e rigorosa a questi standard non solo porta a un approccio a cascata, ma fornisce anche un grado molto elevato di formalizzazione dello sviluppo.
Requisiti GOST
GOST 12207, in contrasto con gli standard della 19a e 34a serie, descrive lo sviluppo del software come un insieme di processi principali e ausiliari che possono operare dall'inizio alla fine del progetto. Il modello del ciclo di vita può essere selezionato in base alle caratteristiche del progetto. Pertanto, questo GOST non vieta esplicitamente l'uso di un approccio iterativo, ma non ne consiglia esplicitamente l'uso. GOST 12207 è anche più flessibile in termini di requisiti per la formalità del processo di sviluppo. Contiene solo indicazioni sulla necessità di documentare i principali risultati di tutti i processi, ma non contiene elenchi di documenti richiesti e istruzioni sul loro contenuto.
Pertanto, GOST 12207 consente lo sviluppo di software iterativo e meno formalizzato.
Oltre agli standard nazionali e internazionali, esistono diversi approcci alla certificazione del processo di sviluppo. I più famosi in Russia sono, a quanto pare, CMM e CMMI.
CMM (Capability Maturity Model) è un modello di maturità dei processi di sviluppo software, progettato per valutare il livello di maturità del processo di sviluppo in una determinata azienda. Secondo questo modello, ci sono cinque livelli di maturità del processo di sviluppo. Il primo livello corrisponde allo sviluppo "come va", quando gli sviluppatori si dedicano a ciascun progetto come un'impresa. Il secondo corrisponde a processi più o meno consolidati, quando è possibile contare con sufficiente sicurezza su un esito positivo del progetto. Il terzo corrisponde alla presenza di processi sviluppati e ben descritti utilizzati nello sviluppo, e il quarto corrisponde all'uso attivo di metriche nel processo di gestione per fissare obiettivi e monitorarne il raggiungimento. Infine, il quinto livello si riferisce alla capacità dell'azienda di ottimizzare il processo secondo necessità.
Requisiti CMM e CMMI
Dopo l'avvento di CMM, iniziarono a essere sviluppati modelli di maturità specializzati per creare sistemi di informazione, per il processo di selezione dei fornitori e alcuni altri. Sulla base di essi è stato sviluppato un modello integrato CMMI (Capability Maturity Model Integration). Inoltre, in CMMI si è tentato di superare le carenze di CMM che si erano manifestate a quel tempo: un'esagerazione del ruolo delle descrizioni formali dei processi, quando la presenza di una certa documentazione era valutata molto più in alto di una semplice, consolidata, ma non processo descritto. Tuttavia, CMMI si concentra anche sull'utilizzo di un processo altamente formalizzato.
Pertanto, la base dei modelli CMM e CMMI è la formalizzazione del processo di sviluppo. Rivolgono gli sviluppatori all'implementazione di un processo descritto in dettaglio nei regolamenti e nelle istruzioni, che, a loro volta, non possono non richiedere lo sviluppo di una grande quantità di documentazione di progetto per un controllo e un reporting adeguati.
La relazione di CMM e CMMI con lo sviluppo iterativo è più indiretta. Formalmente, nessuno dei due ha avanzato requisiti specifici per aderire a un approccio a cascata o iterativo. Tuttavia, secondo alcuni esperti, CMM è più compatibile con l'approccio a cascata, mentre CMMI consente anche un approccio iterativo.
Naturalmente, RUP è una metodologia iterativa. Sebbene formalmente l'esecuzione obbligatoria di tutte le fasi o un numero minimo di iterazioni non sia indicato da nessuna parte in RUP, l'intero approccio si concentra sul fatto che ce ne sono parecchie. Il numero limitato di iterazioni non consente di sfruttare appieno RUP. Allo stesso tempo, RUP può essere utilizzato anche in progetti quasi a cascata, che in realtà includono solo un paio di iterazioni: una nella fase di costruzione e l'altra nella fase di trasferimento. A proposito, questo è il numero di iterazioni che viene effettivamente utilizzato nei progetti a cascata. Dopotutto, il test e il funzionamento di prova del sistema comportano l'esecuzione di correzioni, che possono comportare determinate azioni relative all'analisi, alla progettazione e allo sviluppo, ovvero, di fatto, sono un ulteriore passaggio attraverso tutte le fasi di sviluppo.
Metodologia RUP
Per quanto riguarda la formalità della metodologia, RUP mette a disposizione dell'utente un ventaglio di possibilità molto ampio. Se esegui tutto il lavoro e le attività, crei tutti gli artefatti e in modo abbastanza formale (con un revisore ufficiale, con la preparazione di una revisione completa sotto forma di documento elettronico o cartaceo, ecc.) conduci tutte le revisioni, RUP può rivolgersi una metodologia estremamente formale e ponderosa. Allo stesso tempo, RUP ti consente di sviluppare solo quegli artefatti ed eseguire solo quei lavori e attività che sono necessari in un particolare progetto. E gli artefatti selezionati possono essere eseguiti e rivisti con un grado arbitrario di formalità. È possibile richiedere uno studio dettagliato e un'attenta esecuzione di ciascun documento, la fornitura di una revisione altrettanto accuratamente eseguita e formalizzata e persino, seguendo la vecchia pratica, l'approvazione di ciascuna di tali revisioni presso il consiglio scientifico e tecnico dell'impresa. Puoi limitare e-mail o schizzo su carta. Inoltre, c'è sempre un'altra possibilità: formare un documento nella tua testa, cioè pensare alla questione rilevante e prendere una decisione costruttiva. E se questa decisione riguarda solo te, limitati, ad esempio, a un commento nel codice del programma.
Pertanto, RUP è una metodologia iterativa con una gamma molto ampia possibili soluzioni in termini di formalizzazione del processo di sviluppo.
Riassumiamo la seconda parte dell'articolo. RUP, a differenza della maggior parte delle altre metodologie, consente di scegliere il grado di formalizzazione e iterazione del processo di sviluppo in un'ampia gamma, a seconda delle caratteristiche dei progetti e dell'organizzazione in via di sviluppo.
E perché questo è così importante - discuteremo nella parte successiva.
