Modello di maturità delle capacità (CMM). Norme ISO, SW-CMM

Modelli di miglioramento

Migliorare i processi dei requisiti

Il paradigma della gestione della qualità, come modo di organizzare la produzione, è apparso molto tempo fa. Idee incorporate nel gruppo di standard ISO9000 1) , sono radicati, in particolare, in tali invenzioni "sovietiche" come supporto per proposte di razionalizzazione, tutoraggio, ecc.

Nel moderno concetto di organizzazione aziendale orientata ai processi, il processo di miglioramento continuo della qualità occupa una delle posizioni chiave.

Per quanto riguarda l'industria del software, oltre alla serie ISO9000, gli standard qualitativi di maggior successo sono SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

L'introduzione attiva dei metodi di gestione della qualità in Occidente iniziò all'inizio degli anni '60. La filosofia degli approcci CPI (Continuous Process Improvement) e TQM (Total Quality Management) ha costituito la base degli standard della serie ISO9000. L'ascesa dell'economia del Giappone del dopoguerra fu in gran parte dovuta alle idee incarnate in TQM.

Qualità è un termine che per alcuni indica la necessità di fare ciò che vuole il consumatore, per altri ciò che soddisfa le sue esigenze. La gestione della qualità, come definita nella norma ISO 9001:2000, si basa principalmente sul fatto che le persone ottengono risultati migliori quando sanno cosa stanno facendo. .

Pertanto, prima di iniziare qualsiasi azione, dovresti ottenere risposte alle domande: cosa è necessario fare, chi controllerà cosa è stato fatto, come dovrebbe essere fatto e come determinare che il lavoro sia completato? Devi anche considerare come gestirai il processo e come può essere migliorato.

Principi di base della ISO9000:

• Attenzione alle esigenze del cliente;
• Ruolo di leadership attiva del management;
• Coinvolgimento degli esecutori nei processi di miglioramento;
• Implementazione dell'approccio per processi;
• Approccio sistemico alla gestione;
• Garantire il miglioramento continuo;
• Processo decisionale basato sui fatti;
• Rapporti reciprocamente vantaggiosi con i fornitori.

L'indubbio vantaggio degli standard di questo gruppo è dovuto al fatto che sono stati testati in molte aziende nel mondo. Tuttavia, le raccomandazioni di questi standard sono di natura piuttosto generale e non tengono conto delle specificità delle imprese IT. Per questo, sono stati sviluppati approcci specializzati, discussi di seguito.

Lo standard CMM (Capability Maturity Model) è stato sviluppato dall'Institute of Engineering Software(SEI) presso la Carnegie Mellon University.

Lo scopo dello standard è valutare il livello di "maturità" (livelli di maturità) dell'organizzazione - sviluppatore di software. Si distinguono cinque livelli: iniziale, ripetibile, definito, gestito e ottimizzante (per maggiori dettagli, vedere). Questo standard è diventato ampiamente noto, un numero significativo di aziende IT occidentali è certificato secondo CMM.

Nel 2000, SEI ha rilasciato CMMI-SE/SW, un modello integrato per migliorare le capacità di progettazione sia del software che del sistema.

CMMI-SE/SW ha due forme. La rappresentazione a fasi è conforme alla struttura SW-CMM con piccoli perfezionamenti ai nomi dei livelli. I cinque livelli di maturità contengono le 22 aree del flusso di lavoro mostrate nella Tabella 14.1. (UMC/SEI, 2000a). La rappresentazione continua ha una visione diversa: le stesse 22 aree sono strutturate in 4 categorie: gestione dei processi, gestione dei progetti, progettazione e supporto (CMU/SEI, 2000b).

In una visione continua, invece dei livelli di maturità, sono definiti sei livelli di capacità per ogni area di processo. Questa visualizzazione consente a ciascuna organizzazione di decidere quale livello di capacità necessita in ciascuna delle 22 aree di processo.

Come nel CMM, in questo standard al livello 2 è presente un'area denominata "Gestione dei requisiti", ma, a differenza dello standard precedente, al livello 3 è presente anche un'area separata di Sviluppo dei requisiti. Posizionare quest'area al Livello 3 non implica che i requisiti per i progetti organizzativi che non raggiungono il Livello 2 non debbano essere raccolti e documentati. La gestione dei requisiti è vista come un modo per aiutare a creare progetti più prevedibili e meno caotici, che è l'essenza del CMM di livello 2. Adottando un processo per la gestione del cambiamento e il controllo dello stato dei requisiti, un'organizzazione può porre maggiore enfasi sullo sviluppo di requisiti di alta qualità.

Tabella 14.1.
livello di maturità	Nome	Aree di processo
	Elementare	(NO)
	Gestito	Gestione dei requisiti Pianificazione del progetto Monitoraggio e controllo del progetto Gestione degli accordi con i fornitori Misurazione e analisi Garanzia di qualità del processo e del prodotto Gestione della configurazione
	Definito	Sviluppo dei requisiti Soluzione tecnica Integrazione del prodotto Verifica del processo di convalida Focus Organizzazione Definizione del processo Apprendimento organizzativo Gestione integrata dei progetti Gestione del rischio Analisi e risoluzione dei problemi
	gestito quantitativamente	Prestazione processi organizzativi Gestione quantitativa del progetto
	Ottimizzazione	Innovazioni organizzative e loro diffusione Analisi casuale e risoluzione

Area del processo di gestione dei requisiti

Gli argomenti chiave includono il modo in cui il team di sviluppo dovrebbe acquisire una comprensione dei requisiti e risolvere i problemi con i clienti, coinvolgere le parti interessate del progetto nel lavorare con i requisiti e gestire il cambiamento. A differenza di SW-CMM, la tracciabilità (una delle proprietà chiave dei requisiti) è inclusa nell'area di processo considerata. Le seguenti qualità di tracciamento sono discusse nello standard:

• fornire una registrazione delle fonti dei requisiti di basso livello o secondari;
• ricondurre ogni requisito a requisiti secondari e organizzarlo per funzione, oggetto, processo e lavoratore;
• stabilire collegamenti orizzontali tra requisiti appartenenti alla stessa tipologia.

Area del processo di ingegneria dei requisiti

In CMMI-SE/SW sono descritte tre serie di tecniche di sviluppo dei requisiti:

• tecniche che definiscono un set completo di requisiti del cliente, che vengono poi utilizzati per sviluppare i requisiti per il prodotto (identificare i bisogni delle parti interessate nel progetto; convertire bisogni e vincoli in requisiti del cliente);
• tecniche che determinano l'insieme completo dei requisiti per il prodotto (installare i componenti del prodotto; stabilire i requisiti per i componenti del prodotto; determinare i requisiti dell'interfaccia);
• tecniche per ottenere requisiti secondari, comprendere i requisiti e la loro conferma (stabilire concetti e scenari operativi; determinare la funzionalità richiesta del sistema; analizzare i requisiti secondari; valutare il costo, il tempo e il rischio di creare un prodotto; approvare i requisiti).

Sia il CMM che il CMMI articolano gli obiettivi che un progetto o un'organizzazione di sviluppo software dovrebbe sforzarsi di raggiungere vari campi processi. Raccomandano anche tecnica aiutando a raggiungere questi obiettivi.

CMMI-SE/SW regola la relazione tra la gestione dei requisiti, lo sviluppo dei requisiti e altre aree di processo (Figura 14.1).

05.04.2007 Vyacheslav Pankratov

Si parla molto in questi giorni di qualità del software e sistemi di informazione, sono in corso studi che dimostrano la dipendenza della qualità e dell'efficienza dei processi aziendali automatizzati. La qualità del software da un concetto astratto e intangibile si trasforma in una metrica complessiva per valutare una soluzione software, un progetto per la sua implementazione, il processo di creazione e il livello di utilizzo dei sistemi informativi nel loro complesso. Cosa determina la qualità dei programmi e come puoi influenzarla?

Oggi si parla molto della qualità del software e dei sistemi informativi, si stanno conducendo ricerche che dimostrano la dipendenza della qualità e dell'efficienza dei processi aziendali automatizzati. La qualità del software da un concetto astratto e intangibile si trasforma in una metrica complessiva per valutare una soluzione software, un progetto per la sua implementazione, il processo di creazione e il livello di utilizzo dei sistemi informativi nel loro complesso. Cosa determina la qualità dei programmi e come puoi influenzarla?

Ovviamente, la qualità del software dipende direttamente dalla qualità del suo processo di produzione. Gestendo il processo produttivo e monitorando gli indicatori di performance di tutte le sue fasi tecnologiche, è possibile influenzare la qualità del prodotto. Parlando delle caratteristiche dei programmi, possiamo individuare metriche quantitative di facile comprensione e analisi, relative alla qualità del codice del programma (complessità del codice ciclomatico - la complessità della struttura del modulo, ad esempio, il numero di percorsi indipendenti in Esso); il numero di righe di codice assegnate agli artefatti del design repository, ecc.; test (che coprono rami di codice e moduli con script di test, il rapporto tra il numero di bug rilevati prima e dopo il rilascio del prodotto, le dinamiche di rilevamento dei bug, ecc.); copertura dei requisiti per la conformità alle raccomandazioni per l'interfaccia dell'applicazione e le piattaforme operative. Tuttavia, quando si passa al livello di processo di garanzia della qualità dei programmi sviluppati, sorgono alcune difficoltà nella comprensione della qualità di questo processo. In effetti, come, ad esempio, valutare e misurare l'efficacia dell'uno o dell'altro metodo di sviluppo, se non ci sono praticamente progetti di sviluppo per due sistemi software identici, e ancora di più, non ci sono due team di sviluppo identici per esperienza e competenze? Giudicato da risultato finale non è possibile: oltre alle condizioni di processo per la produzione del software (la metodologia utilizzata, la struttura del team di progetto, le modalità di comunicazione con il cliente), le condizioni del progetto (termini, costo e volume delle risorse) spesso variano notevolmente. Una considerazione più dettagliata del processo di test del software - una componente tecnologica del processo di produzione - rivela il problema della scelta delle metriche di efficienza del test.

Oltre a una valutazione diretta dell'attuale livello di efficienza di un particolare processo, esiste un compito più interessante: aumentare il livello di efficienza o, come si suol dire, livello di maturità processi. Quando vengono risolti i problemi di base della pianificazione e della conduzione del lavoro di test in integrazione con il processo di sviluppo del software, sorge il compito di trovare schemi organizzativi e procedurali ottimali per l'esecuzione del lavoro. Dopo aver risposto alle domande "chi" e "quando", bisogna cercare le risposte alle domande "come, in che modo", "come misurare i risultati", "come controllare", "come lavorare in modo più efficiente", e anche “come gestire e sviluppare il processo sulla base dei dati e dell'esperienza.

Nella pratica quotidiana - quando si lavora con strumenti specifici - i professionisti IT ei project manager sviluppano una forte opinione sulla natura tecnologica di tutti i problemi associati alla qualità del software e ai livelli di maturità del processo di sviluppo del software che vengono raggiunti. Di conseguenza, la fiducia promossa dal fornitore nel potere del software per il miglioramento della qualità nella pratica diventa il terreno fertile per decisioni irragionevoli di implementare metodologie o automatizzare i processi di sviluppo, a partire dall'implementazione di specifiche soluzioni software. Tuttavia strutture moderne l'automazione dei processi di sviluppo sono piattaforme talmente flessibili e personalizzabili da richiedere uno studio approfondito preliminare della componente di processo con successiva implementazione e adattamento a specifiche condizioni produttive.

Nel 1980 si sviluppò il Software Engineering Institute della Carnegie Mellon University modello di maturità del processo di sviluppo del software(Capability Maturity Model for Software, CMM), che è stato successivamente sviluppato in CMMI (Capability Maturity Model Integration), un certificato de facto del livello di maturità dello sviluppo riconosciuto nell'industria del software. Per analogia con il mondo dello sviluppo del software e con i modelli esistenti della maturità dei loro processi, considereremo i modelli della maturità del processo di test.

Testare il modello di maturità

Modello di maturità del test del softwareè un approccio sistematico allo sviluppo del processo di test, che offre un sistema di elementi di processi efficaci e modi per raggiungere specifici obiettivi di processo. Sulla base del modello di maturità, è possibile risolvere due compiti principali dello sviluppo del processo: comprendere e correggere l'attuale processo di test e identificare le aree di miglioramento. La pratica dimostra che i cambiamenti di processo sono possibili solo sulla base di una chiara comprensione da parte del management della necessità di apportare tali cambiamenti: qualsiasi cambiamento strutturale e procedurale è impossibile senza la volontà politica del management. Oltre a ricevere supporto gestionale e risorse necessarie, apportare modifiche al processo di test del lavoro richiede una pianificazione chiara, come qualsiasi altra attività di progetto.

Il consulente di test Terry Weatheril è stato uno dei primi a confrontare i modelli di maturità dei test esistenti nel 2001 e ha identificato sei modelli:

Testability Maturity Model (TMM);

Software Testing Maturity Model (TMMSW);

Miglioramento del processo di prova (TPI);

Test Organisation Maturity (TOM);

Programma di valutazione dei test (TAM);

Proposta di valutazione e test SW-CMM Key Process Areas (SW-CMM KPA).

Poi sono state apportate modifiche fondamentali ad alcuni modelli; Pertanto, il modello TOM (è stato creato e sviluppato da Gerrard Consulting) offre un insieme aggiornato di metriche che descrivono il processo di test stesso (la durata delle iterazioni del test, il rapporto tra scenari di test e requisiti funzionali, ecc.), che vengono raccolti e analizzato nella fase di descrizione del processo esistente.

Tra i sei modelli di maturità del test del software, professionisti e consulenti ne identificano due: TMMSW, sviluppato presso l'Illinois Institute of Technology, e TPI, proposto da Sogeti. Entrambi i modelli si sono diffusi principalmente per la loro semplicità, nonché per le pratiche proposte di audit interni che possono essere svolte da specialisti di un'azienda che ha intrapreso la strada del miglioramento dei processi. Considera la struttura dei modelli di maturità del test del software utilizzando il modello TMM come esempio.

Il modello TMMSW, scelto da Thomas Staab, uno dei principali consulenti nel campo del test del software, è il più interessante da applicare, perché, insieme alla facilità di comprensione e utilizzo delle pratiche, consente alle organizzazioni di condurre valutazioni (assessment) su i propri e si avvicinano gradualmente ai propri obiettivi di sviluppo, controllando i risultati intermedi. Nel nostro lavoro abbiamo anche optato per questo modello, data l'impopolarità della pratica di attrarre competenze di terze parti tra le aziende IT nazionali (le aziende cercano di risparmiare sui progetti di investimento, che in sostanza sono progetti di consulenza, nonché progetti che apportano benefici indiretti, che includono modifiche di processo), e vi invitiamo a conoscere la nostra esperienza, che dimostra la disponibilità delle aziende a realizzare autonomamente modifiche interne utilizzando i propri specialisti . L'iterazione dell'approccio è un punto chiave per molte aziende quando si sceglie l'uno o l'altro modello di maturità, in quanto consente di controllare i tempi del progetto per l'implementazione delle modifiche al processo.

Il modello TMMSW è stato sviluppato da un gruppo di specialisti guidati da Ilene Barnstein nel 1996 come estensione e aggiunta al modello SW-CMM. I suoi vantaggi includono la corrispondenza tra i livelli di maturità dei processi di test del software ei livelli di maturità dei processi di sviluppo nel modello SW-CMM. Inoltre, il modello TMMSW può essere utilizzato in integrazione con CMMI, raccomandazioni ISO-9001 e ISO/IEC Std 12207, che consentono di ottenere la certificazione formale e, con un monitoraggio costante sotto forma di audit e ricertificazioni, rimanere a un determinato livello di qualità . Da un lato, questa caratteristica di TMMSW consente l'implementazione di modifiche ai processi nel reparto di test del software sotto forma di un progetto dedicato su scala ridotta rispetto all'implementazione di CMMI in tutta l'organizzazione (che consente di risparmiare denaro e fornisce trasparenza); dall'altro, questo approccio elimina il costo dell'adattamento e dell'abbinamento di più modelli. Parlando di una sorta di rapporto con CMMI, vorrei sottolineare che questo modello è abbastanza diffuso nel mondo IT e ha guadagnato un alto grado di fiducia in se stesso, il che rende molto più facile per il management motivare il costo di un cambiamento di processo progetto.

Il modello TMMSW offre una pianificazione, implementazione e monitoraggio più semplici del processo di miglioramento. Tra le carenze del modello si può notare la letteratura limitata: il libro Practical Software Testing: A Process-oriented Approach, pubblicato da Springer Professional Computing, è forse l'unico lavoro significativo su questo argomento.

Il modello TMMSW, come il CMM, ha cinque livelli di maturità.

Livello 1 - caotico. Il processo di test del software è di natura caotica, che contraddistingue la maggior parte delle start-up. Il processo di test non è definito come un'attività dedicata e non è separato dal processo di debug del codice. Il test viene eseguito dopo che il codice è stato generato e il sistema è stato costruito o assemblato. Lo scopo del test è dimostrare che l'applicazione funziona. Questo livello è caratterizzato da personale non addestrato, mancanza di risorse e strumenti. Il software viene rilasciato senza il consenso formale dei tester. Gli obiettivi di livello non sono definiti.

Livello 2 - fase di sviluppo. Il test del software è separato dalla codifica ed è evidenziato come la fase successiva. Lo scopo principale del test è dimostrare che l'applicazione soddisfa i requisiti. Ci sono approcci di base e pratiche di test. Obiettivi di livello: definire attività di sviluppo e test, creare procedure appropriate, avviare il processo di pianificazione dei test, fissare e descrivere le procedure e le tecniche di test di base.

Livello 3 - integrato. Il processo di test è integrato in ciclo vitale sviluppo software. Gli obiettivi del test si basano sui requisiti. Esiste un'organizzazione di test e il test stesso è assegnato attività professionale. Obiettivi di livello: isolare i test in un gruppo separato e definire un programma di formazione tecnica, integrare il processo di test nel ciclo di vita dello sviluppo e controllare anche il processo di test stesso.

Livello 4 - controllo e misurazione. Il test è un processo misurabile e controllato. I processi sono fondamentali ispezioni(revisione) degli artefatti del progetto (piani e scenari di test, messaggi di errore, rapporti sullo stato della versione finale, ecc.) si riferiscono alle attività di test. Il prodotto è testato per la conformità con metriche di qualità come affidabilità, usabilità, manutenibilità. Gli script di test vengono registrati, archiviati nel sistema di gestione dei test e possono essere riutilizzati insieme ai set di dati di test. I difetti rilevati non vengono solo corretti, ma anche analizzati secondo criteri formali: criticità, “peso” del difetto, importanza, durata, ecc. Obiettivi di livello: implementazione di revisioni critiche e programmi di audit a livello di organizzazione/unità alla pari di un programma di test misurato. Valutazione della qualità in corso prodotti software.

Livello 5 - ottimizzazione dei processi, prevenzione degli errori e controllo della qualità. Il test è un processo definito e controllato. È possibile determinare il costo del test insieme agli indicatori di prestazione. Il test come processo si presta a cambiamenti che lo influenzano chiaramente positivamente. Vengono implementate e utilizzate pratiche di prevenzione degli errori e di controllo della qualità. Il test automatizzato viene utilizzato come approccio principale nei test. La progettazione dei test, l'analisi dei risultati ottenuti, l'elaborazione delle descrizioni degli errori, nonché le metriche relative ai test, vengono effettuate utilizzando gli strumenti appropriati. L'approccio del riutilizzo delle pratiche di processo è molto diffuso. Obiettivi di livello: ottimizzazione del processo di test, prevenzione degli errori e controllo di qualità.

Tutti i livelli di maturità elencati, ad eccezione del primo, includono obiettivi di sviluppo, che a loro volta contengono obiettivi secondari, ovvero consentono di operare non solo con attività di alto livello di gestione della qualità del processo di sviluppo software, ma anche formulare operazioni compiti per tutti gli esecutori del progetto. Il controllo e l'analisi delle prestazioni delle attività si ottengono coprendo le cosiddette matrici ATR (Attività - Compiti - Responsabilità) - artefatti a livello di progetto con cui i partecipanti al progetto possono lavorare senza una preparazione preliminare o una formazione a lungo termine. Le matrici ATR definiscono le attività e i compiti che devono essere eseguiti in ogni fase specifica dell'implementazione del modello e fungono sia da "road map" che da una sorta di "lista di controllo" per il processo di implementazione del cambiamento. La presenza di artefatti progettuali offerti dal modello stesso è spesso un criterio essenziale per il successo di un progetto di adattamento e implementazione del modello. A ciascuna attività nella matrice ATR viene assegnata un'attività di controllo, che viene eseguita da manager, sviluppatori/tester o clienti/utenti. Notiamo in particolare che il controllo sul progetto di cambiamento non è assegnato a un gruppo selezionato di persone oa una persona specifica nel progetto, ma è una funzione generale del progetto, a cui sono interessati i partecipanti al progetto di tutti i livelli.

Fino al quinto livello di maturità dei processi di test del software non sono richiesti strumenti speciali o soluzioni integrate, contrariamente alla maturità dei processi di sviluppo, dove sono ad esempio disponibili strumenti per la raccolta e l'analisi dei requisiti e il controllo della versione condizione necessaria raggiungere un certo livello di maturità del processo di sviluppo nel suo complesso. Al quinto livello del modello TMMSW, è possibile utilizzare alcuni strumenti di analisi statistica del codice che consentono di risolvere uno dei compiti target di questo livello di maturità: la prevenzione degli errori identificando sezioni di codice contenenti errori logici in assenza di operatori di rilascio delle risorse o ricerca per variabili inutilizzate o array di memoria. Tuttavia, l'uso di uno strumento speciale non è obbligatorio nemmeno a questo livello; ad esempio, l'approccio quando ci sono due tester per programmatore, uno dei quali è uno sviluppatore di più alto livello- impegnato con i compiti di revisioni critiche del codice, consente anche di risolvere il problema della prevenzione degli errori.

L'uso di metodologie specifiche o il seguire una qualsiasi delle metodologie scelte (RUP, MSF o Scrum) non garantisce inoltre il raggiungimento della qualità del prodotto o il successo del progetto, poiché la metodologia di sviluppo del software funziona solo per un tipo specifico di progetto. Allo stesso modo, per il processo di test del software, nessuna metodologia senza adattamento alle condizioni di un particolare progetto fornisce un risultato garantito. Il modello di maturità del processo è proprio la pratica del raggiungimento di determinati livelli di qualità del processo che è interessante per l'applicazione, che è una struttura di obiettivi e approcci per raggiungerli, consentendo di utilizzare "dentro" una metodologia di sviluppo quasi arbitraria (con il giusto adattamento) e una serie di strumenti. Il modello spiega “cosa e come” fare, ma non “cosa e in quale ordine”.

Pratica

Mettendo in pratica le raccomandazioni dei modelli di maturità del processo di test, l'azienda può non solo vedere i progressi nel formato delle metriche raccolte, ma anche sentire realmente i cambiamenti qualitativi nella modalità di lavoro stessa. Ci sono diversi segni di cambiamenti di processo che vengono avvertiti sia dalla direzione e dai membri del team, sia dai clienti e dai consumatori del prodotto in fase di sviluppo.

Processo cronometrato di rilascio delle versioni con un determinato livello di qualità. Non parla della qualità ideale del prodotto fabbricato o totale assenza difetti: stiamo parlando di fiducia nello stato della versione rilasciata, da parte sia del team di progetto che del team di test.

Regolarità e ripetibilità prevedibile di tutte le fasi del progetto. Nelle condizioni dei livelli iniziali di maturità dei processi di test del software, le attività di test seguono come fase finale del lavoro e spesso "soffrono" a causa del tempo limitato e della mancanza di risorse, che influisce direttamente sulla stabilità delle versioni rilasciate e sulla loro qualità. Con il passaggio a livelli superiori del modello di maturità del processo di test, le attività di test sono sempre più integrate nello sviluppo e nel rilascio delle versioni del prodotto, il che influisce positivamente sull'allocazione delle risorse e dei tempi necessari per completare il lavoro.

Un cambiamento in tale indicatore qualitativo che caratterizza il processo di sviluppo e rilascio del software, come il numero di difetti riscontrati dopo il rilascio della versione del prodotto in operazioni sperimentali o addirittura di produzione. Questo indicatore è molto significativo per il personale dirigente ei servizi. supporto tecnico, che può confermare le dinamiche positive di miglioramento della qualità del software conducendo un'analisi quantitativa e qualitativa delle richieste registrate da clienti o utenti. Punti positivi, secondo le nostre stime, sono associati a miglioramenti pratici nella fase di progettazione e controllo dei collaudi, poiché spesso i difetti mancati sono causati proprio dalla mancanza di tempo per la pianificazione e il monitoraggio del lavoro di collaudo svolto.

Letteratura

Terry Weatherill, Nel labirinto del modello di maturità dei test. Giornale dei professionisti del test del software, 2001.

Thomas Staab, Utilizzo di SW-TMM per migliorare il processo di test. Cresta del vento internazionale.

Vyacheslav Pankratov ([e-mail protetta] ) - Amministratore delegato Società QAExpert (Kiev, Ucraina).

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 del CMM, iniziarono a essere sviluppati modelli di maturità specializzati per la creazione di sistemi informativi, per il processo di selezione dei fornitori e 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, test e operazione di prova sistemi comporta l'esecuzione di correzioni, che possono comportare determinate attività relative all'analisi, alla progettazione e allo sviluppo, ovvero, in realtà, sono un passaggio in più 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. Oppure puoi limitarti a un'e-mail o uno 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 di 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.

Le organizzazioni che lavorano nel campo dello sviluppo, della consegna, dell'implementazione e della manutenzione di software e integrazione di sistemi sentono sempre più che la loro competitività si basa sulla qualità, sul basso costo e sulla producibilità.

I leader di tali organizzazioni non sono sempre in grado di formare una strategia per migliorare e sviluppare la tecnologia delle attività della loro azienda; nel mercato del lavoro degli specialisti qualifiche necessarie chiaramente non abbastanza. Allo stesso tempo, nel campo del miglioramento dei processi tecnologici di sviluppo e funzionamento del software, esperienza internazionale lunghi anni non è stato sufficientemente generalizzato e formalizzato. Solo nei primi anni '90 l'American Software Engineering Institute (SEI) ha formato un modello di maturità tecnologica delle organizzazioni CMM (Capability Maturity Model), determinando i livelli di maturità tecnologica e la loro caratteristiche distintive. Nel corso di un decennio, CMM è stato testato in numerose organizzazioni, la sua efficacia e affidabilità sono state verificate da organizzazioni di ordinazione, fornitori di software, società di sviluppo software personalizzato e programmazione offshore.

Oggi, in occidente, una società di sviluppo ha praticamente grosse difficoltà ad ottenere commesse se non è certificata dalla SMM. I clienti richiedono garanzie sulla producibilità dell'appaltatore, garanzie che l'appaltatore non possa fornire un servizio di bassa qualità.

La valutazione della maturità tecnologica delle imprese può essere utilizzata:

il cliente nella selezione dei best performer (ad esempio, in una gara);

· società di software per valutare sistematicamente lo stato dei propri processi tecnologici e selezionare le aree di miglioramento;

· aziende che decidono di sottoporsi ad un attestato per valutare la “dimensione del disastro”, ovvero il suo stato attuale;

revisori per determinare la procedura di certificazione standard e condurre le valutazioni necessarie;

società di consulenza impegnate nella ristrutturazione di aziende e fornitori di servizi Tecnologie informatiche e relativi servizi.

Con l'aumentare della maturità tecnologica di un'organizzazione, i processi per la creazione e la manutenzione del software diventano più standardizzati e coerenti. Allo stesso tempo, la formalizzazione dei processi consente di standardizzare i risultati attesi dalla loro attuazione e garantire la prevedibilità dei risultati dell'attuazione del progetto.

Maturità del processo (maturità del processo software)- questo è il grado della loro gestibilità, controllabilità ed efficacia. L'aumento della maturità tecnologica si riferisce al potenziale per una maggiore resilienza dei processi e indica il grado di efficienza e coerenza nell'uso dei processi di sviluppo e manutenzione del software in tutta l'organizzazione. L'uso reale dei processi è impossibile senza la loro documentazione e portando all'attenzione del personale dell'organizzazione, senza un costante monitoraggio e miglioramento della loro attuazione. Le capacità di processi ben progettati sono completamente definite. Aumentare la maturità tecnologica dei processi significa che l'efficienza e la qualità dei risultati della loro implementazione possono aumentare costantemente.

Nelle organizzazioni che hanno raggiunto la maturità tecnologica, i processi di creazione e manutenzione del software assumono lo status di standard, sono fissati strutture organizzative e determinare le tattiche e la strategia di produzione. La loro introduzione nella legge comporta la necessità di costruire l'infrastruttura necessaria e creare la necessaria cultura della produzione aziendale che garantisca il mantenimento di metodi, operazioni e procedure appropriate per fare affari anche dopo che coloro che l'hanno creata hanno lasciato l'organizzazione.

Il modello CMM sviluppa le disposizioni sul sistema di qualità dell'organizzazione, formando i criteri per il suo perfezionamento: cinque livelli di maturità tecnologica, che, in linea di principio, possono essere raggiunti dall'organizzazione di sviluppo. Il più alto - il quarto e il quinto livello - è in realtà una caratteristica delle organizzazioni che hanno padroneggiato i metodi di sviluppo collettivo, in cui i processi di creazione e manutenzione del software sono completamente automatizzati e tecnologicamente supportati.

Dal 1990, SEI, con il supporto delle agenzie governative statunitensi e delle organizzazioni di sviluppo software, ha costantemente sviluppato e migliorato questo modello, tenendo conto di tutti gli ultimi risultati nel campo della creazione e manutenzione del software.

SMM è materiale metodico, definendo le regole per la formazione di un sistema gestionale per la realizzazione e manutenzione del software e le modalità per il miglioramento graduale e continuo della cultura produttiva. Lo scopo di CMM è quello di fornire alle organizzazioni di sviluppo le indicazioni necessarie per la scelta di una strategia per migliorare la qualità dei processi analizzando il grado della loro maturità tecnologica ei fattori che maggiormente incidono sulla qualità dei prodotti. Concentrandosi su un piccolo numero delle operazioni più critiche e migliorando sistematicamente l'efficienza e la qualità della loro esecuzione, un'organizzazione può quindi ottenere un costante miglioramento continuo nella cultura della creazione e della manutenzione del software.

Il CMM è un modello descrittivo nel senso che descrive gli attributi essenziali (o chiave) che determinano a quale livello di maturità tecnologica si trova un'organizzazione. Si tratta di un modello normativo nel senso che una descrizione dettagliata delle metodologie stabilisce il livello di organizzazione necessario per realizzare progetti di varia complessità e durata nell'ambito di contratti con agenzie governative statunitensi. CMM non è una prescrizione, non prescrive come dovrebbe svilupparsi un'organizzazione. Il CMM descrive le caratteristiche dell'organizzazione per ogni livello di maturità tecnologica, senza dare alcuna istruzione su come passare da un livello all'altro. Un'organizzazione può impiegare diversi anni per passare dal primo al secondo livello e pochissimo tempo per passare da un livello all'altro. Il processo di miglioramento della tecnologia di creazione del software si riflette in piani strategici organizzazione, la sua struttura, le tecnologie utilizzate, la cultura sociale generale e il sistema di gestione.

Ad ogni livello vengono stabiliti requisiti in base ai quali si ottiene la stabilizzazione degli indicatori più significativi dei processi. Il raggiungimento di ogni livello di maturità tecnologica è il risultato della comparsa di un certo numero di componenti nei processi di sviluppo del software, che a sua volta porta ad un aumento della loro produttività e qualità. Sulla fig. La Figura 1.7 mostra cinque livelli di maturità tecnologica CMM.

Riso. 1.7. Cinque livelli di maturità tecnologica SMM

Le iscrizioni sulle frecce definiscono le caratteristiche del miglioramento dei processi quando si passa da un livello all'altro.

I livelli dal secondo al quinto possono essere caratterizzati attraverso operazioni finalizzate alla standardizzazione e (o) modernizzazione dei processi di creazione del software, e attraverso le operazioni che costituiscono i processi stessi della sua creazione. Allo stesso tempo, il primo livello è, per così dire, la base, il fondamento per analisi comparativa livelli superiori.

Al livello 1 (iniziale), i processi di base di creazione e manutenzione del software sono casuali e caotici. Il successo del progetto dipende interamente dagli sforzi individuali del personale. A questo livello, di norma, l'organizzazione non dispone di un ambiente stabile necessario per la creazione e la manutenzione del software.

Il successo del progetto in questo caso, di norma, dipende interamente dal grado di energia ed esperienza della direzione e dal livello professionale degli artisti. Può succedere che un leader energico superi tutti gli ostacoli nel processo del progetto e raggiunga il rilascio di un prodotto software veramente fattibile. Ma dopo che un tale leader ha lasciato il suo posto, non vi è alcuna garanzia che il prossimo progetto di questo tipo avrà successo. Con assenza livello richiesto gestione del progetto, anche la tecnologia avanzata non può salvare la situazione.

I processi al primo livello sono caratterizzati dalla loro imprevedibilità dovuta al fatto che la loro composizione, scopo e sequenza nel processo di attuazione del progetto cambiano in modo casuale a seconda della situazione attuale. Di conseguenza, i fondi assegnati vengono spesi in eccesso e gli orari di lavoro vengono interrotti. Addestramento capace e professionisti esperti nelle organizzazioni è il prerequisito principale per il successo a tutti i livelli di maturità, ma al primo livello è l'unica opportunità per ottenere almeno risultati positivi.

Al livello 2 (il livello dei processi ripetibili), i processi di gestione del progetto forniscono un controllo continuo del costo del progetto, della pianificazione e delle funzioni eseguite. La disciplina del progetto è tale che è possibile prevedere il successo dei progetti per creare prodotti software simili.

A questo livello, pianificazione lavoro di progettazione e la gestione di nuovi progetti si basa sull'esperienza di progetti simili portati a termine con successo. La caratteristica principale del secondo livello è la presenza di processi di project management efficaci, formalizzati e documentati, che consentono di utilizzare l'esperienza positiva di progetti completati con successo. I processi efficaci sono quelli documentati, effettivamente utilizzati, misurabili e aggiornabili. È essenziale che il personale sia addestrato al loro utilizzo.

Ogni livello di CMM, a partire dal secondo, è caratterizzato dalla presenza di un numero di cosiddetti gruppi di processi chiave (KPA). Il modello CMM contiene 18 di questi gruppi, l'ultima versione del modello CMMI contiene 20 gruppi. Il CMM di livello 2 è caratterizzato dalla presenza dei seguenti processi nell'organizzazione (i loro nomi corrispondono a CMMI):

gestione dei requisiti;

gestione della configurazione;

pianificazione del progetto;

monitoraggio e controllo del progetto;

gestione dei contratti;

misurazione e analisi;

garantire la qualità del processo e del prodotto.

I processi al secondo livello possono essere caratterizzati come ordinati in quanto sono pianificati in anticipo e la loro attuazione è strettamente controllata, grazie alla quale si ottiene la prevedibilità dei risultati del progetto. Man mano che i progetti crescono e diventano più complessi, l'attenzione si sposta da aspetti tecnici la loro attuazione sugli aspetti organizzativi e gestionali. L'esecuzione dei processi richiede alle persone di lavorare in modo più efficace e coerente, il che, a sua volta, richiede lo studio di best practice documentate al fine di migliorare l'eccellenza professionale.

Al livello 3 (il livello dei processi standardizzati), i processi di sviluppo del software sono documentati, standardizzati e rappresentano un unico sistema tecnologico obbligatorio per tutti i reparti dell'organizzazione. Tutti i progetti utilizzano un'unica tecnologia per la creazione e la manutenzione del software che è stato testato, approvato ed elevato allo stato di standard.

A questo livello, ai processi di livello 2 si aggiungono i seguenti processi:

specifica dei requisiti;

integrazione del prodotto;

verifica;

certificazione;

standardizzazione dei processi organizzativi;

· formazione scolastica;

gestione integrata dei progetti;

· Gestione dei rischi;

Analisi e decisione.

Il criterio principale per l'utilizzo e, se necessario, l'adeguamento dei processi a questo livello è aiutare la direzione e specialisti tecnici nel migliorare l'efficienza dell'attuazione del progetto. A questo livello, viene creato un gruppo speciale nell'organizzazione responsabile della composizione delle operazioni che compongono i processi: il gruppo di processi di ingegneria del software (SEPG).

Sulla base di un'unica tecnologia per ogni progetto, è possibile sviluppare i propri processi, tenendo conto delle sue caratteristiche. Tali processi in CMM sono chiamati "processi di sviluppo software orientati al progetto" (processo software definito dal progetto).

La descrizione di ciascun processo include le condizioni per la sua esecuzione, i dati di input, gli standard e le procedure per l'esecuzione, i meccanismi di verifica (ad esempio, pareri di esperti), dati di output e condizioni di terminazione. La descrizione del processo include anche informazioni sugli strumenti necessari per completarlo e l'indicazione del ruolo responsabile della sua esecuzione.

Lo scopo principale del livello 4 (il livello dei processi gestiti) è l'attuale controllo sui processi. La direzione deve garantire che i processi siano eseguiti all'interno della qualità specificata. Potrebbero esserci inevitabili perdite e picchi temporanei nei risultati misurati che richiedono un intervento, ma nel complesso il sistema deve essere stabile.

Al livello 4, vengono aggiunti i seguenti processi:

gestione delle prestazioni e della produttività;

Gestione quantitativa del progetto.

A questo livello, viene applicata in pratica una valutazione dettagliata della qualità sia dei processi di creazione che del prodotto software stesso. In questo caso si applicano criteri di valutazione quantitativi.

Nell'ambito dell'intera organizzazione, è in fase di sviluppo un unico programma per il controllo quantitativo della produttività della creazione del software e della sua qualità. Per facilitare l'analisi dei processi, viene creato un unico database dei processi per la creazione e la manutenzione del software per tutti i progetti svolti nell'organizzazione. Si stanno sviluppando metodi universali quantificazione la produttività dei processi e la qualità della loro attuazione. Ciò consente l'analisi quantitativa e la valutazione dei processi di creazione e manutenzione del software.

I risultati dei processi al quarto livello diventano prevedibili, perché sono misurabili e variano all'interno delle restrizioni quantitative date. A questo livello diventa possibile pianificare in anticipo la qualità specificata dei processi e dei prodotti finali.

Lo scopo principale del livello 5 (il livello dei processi ottimizzati) è il costante miglioramento e la modernizzazione dei processi di creazione e manutenzione del software. Ai fini della modernizzazione pianificata della tecnologia di sviluppo del software, viene creata un'unità speciale nell'organizzazione, le cui principali responsabilità sono la raccolta di dati sull'implementazione dei processi, la loro analisi, la modernizzazione di quelli esistenti e la creazione di nuovi processi , la loro verifica per progetti pilota e dando loro lo status di standard aziendali.

Al livello 5 vengono aggiunti i seguenti processi:

introduzione di innovazioni tecnologiche e organizzative;

analisi causa-effetto e problem solving. I processi di creazione e manutenzione del software sono caratterizzati da

costantemente migliorati, poiché l'organizzazione compie continui sforzi per modernizzarli. Questo miglioramento si estende sia all'identificazione di capacità aggiuntive dei processi utilizzati, sia alla creazione di nuovi processi ottimali e all'uso di nuove tecnologie.

Le innovazioni che possono portare i maggiori benefici sono standardizzate e adattate al sistema tecnologico in tutta l'organizzazione. Il personale coinvolto nella realizzazione del progetto analizza i difetti e individua le cause del loro verificarsi. I processi di sviluppo del software vengono valutati per prevenire il ripetersi di situazioni che portano a difetti e i risultati della valutazione vengono presi in considerazione nei progetti successivi.

Ogni livello successivo fornisce inoltre una visibilità più completa dei processi di creazione e manutenzione del software.

Al primo livello, i processi sono amorfi ("scatole nere") e la loro visibilità è molto limitata. Fin dall'inizio, la composizione e lo scopo delle operazioni non sono praticamente definiti, il che crea notevoli difficoltà nel determinare lo stato del progetto e il suo avanzamento. I requisiti per l'esecuzione dei processi sono fissati in modo incontrollabile. Lo sviluppo del software agli occhi dei manager (specialmente quelli che non sono essi stessi programmatori) a volte sembra magia nera.

Al secondo livello, viene controllato il soddisfacimento dei requisiti dell'utente e la creazione del software, poiché viene definita la base per i processi di gestione del progetto. Il processo di creazione del software può essere visto come una sequenza di "scatole nere" che possono essere controllate nei punti di transizione da una "scatola" all'altra - fasi fisse. Anche se il manager non sa cosa si sta facendo "dentro la scatola", viene stabilito con precisione quale dovrebbe essere il risultato del processo e vengono determinati i punti di controllo per il suo inizio e la sua fine. Pertanto, la direzione può riconoscere i problemi nei punti di interazione black-box e rispondere tempestivamente.

Al terzo livello viene definita la struttura interna delle "scatole nere", ovvero le attività che compongono i processi. Struttura interna rappresenta il modo in cui i processi standard in un'organizzazione vengono applicati a progetti specifici. Il collegamento di gestione e gli esecutori conoscono i propri ruoli e responsabilità all'interno del progetto al livello di dettaglio richiesto. La direzione è preparata in anticipo per i rischi che possono sorgere durante l'attuazione del progetto. Poiché i processi standardizzati e documentati diventano "trasparenti" per la revisione, i dipendenti che non sono direttamente coinvolti nel progetto possono ricevere informazioni accurate sullo stato attuale in modo tempestivo.

Al quarto livello, l'esecuzione dei processi è strettamente legata agli strumenti, il che consente di determinare le caratteristiche quantitative della loro intensità di lavoro e qualità dell'esecuzione. I manager, avendo una base oggettiva di misurazioni quantitative, hanno l'opportunità di pianificare con precisione le fasi e le fasi del progetto, prevedere l'avanzamento del progetto e possono rispondere tempestivamente e adeguatamente ai problemi emergenti. Con la riduzione delle possibili deviazioni dai termini, dai costi e dalla qualità dati nel processo di attuazione del progetto, la loro capacità di prevedere i risultati è in costante aumento.

Al quinto livello, al fine di migliorare la qualità dei prodotti e aumentare l'efficienza della sua creazione, si lavora costantemente e sistematicamente per creare nuovi metodi e tecnologie migliorati per la creazione di software. Si richiama l'attenzione non solo sui processi e sulle tecnologie già utilizzati, ma anche su quelli nuovi e più efficienti. I manager possono quantificare l'impatto e l'efficacia dei cambiamenti nella tecnologia di sviluppo e manutenzione del software.

Il quarto e il quinto livello sono rari nell'industria del software. Pertanto, se diverse centinaia di aziende nel mondo hanno raggiunto il terzo livello, allora c'erano 62 aziende del quinto livello (secondo i dati SEI per il 2002) e 72 del quarto. Alcuni non sono interessati a pubblicizzare il loro tecnologie organizzative, altri eseguono la certificazione semplicemente sotto la pressione del cliente.

Ci vogliono dieci anni o più per raggiungere i più alti livelli di SMM. Ma anche il livello 3 ti consente di entrare con coraggio nell'arena internazionale. Per utilizzare SMM, un'azienda non ha bisogno di cercare dipendenti con abilità uniche, è sufficiente che comprenda l'idea generale. La descrizione del modello CMM specifica in dettaglio cosa deve essere fatto per svilupparsi secondo questo modello. Qualsiasi manager della classe media è in grado di seguire le azioni regolamentate del CMM.

ultima versione CMM 1.1 si rivolge principalmente alle grandi aziende impegnate nella realizzazione di grandi progetti, ma può essere utilizzato anche da gruppi di due o tre persone o da singoli programmatori per portare a termine piccoli progetti (fino a tre mesi). In tali casi, il modello CMM può svolgere un ruolo fondamentale, poiché la ricezione di nuovi ordini è in gran parte determinata dalla qualità dell'attuazione dei progetti precedenti. I piccoli gruppi saranno abbastanza soddisfatti del livello 2, poiché per un piccolo progetto una deviazione dalla scadenza di un paio di settimane non è importante.

Dal 2002 è stata ufficialmente distribuita una speciale versione di integrazione di CMMI. Questo nuovo sviluppo SEI, che copre tutti gli aspetti delle attività dell'azienda: dallo sviluppo e selezione di un appaltatore alla formazione, implementazione e manutenzione. Inoltre, il modello CMMI viene esteso con approcci dall'ingegneria dei sistemi. Questo modello include gli sviluppi realizzati durante la progettazione della versione CMM 2.0 (non è stata completata), le cui principali modifiche miravano a chiarire i processi per le aziende di quarto e quinto livello, che è più rilevante per i progetti americani su larga scala.

Il modello CMM è piuttosto pesante e importante, ma non dovrebbe essere utilizzato come unica base che determina l'intero processo di sviluppo del software. Era destinato principalmente alle aziende che sviluppano software per il Dipartimento della Difesa degli Stati Uniti. Questi sistemi sono caratterizzati dalle loro grandi dimensioni e dalla lunga durata, nonché dalla complessità dell'interfaccia con hardware e altri sistemi software. Team di programmatori piuttosto grandi stanno lavorando alla creazione di tali sistemi, che devono soddisfare i requisiti e gli standard sviluppati dal Ministero della Difesa.

Gli svantaggi di SMM includono quanto segue:

1. Il modello si concentra esclusivamente sulla gestione del progetto e non sul processo di creazione di un prodotto software. Il modello non tiene conto di fattori così importanti come l'uso di determinati metodi, come la prototipazione, metodi formali e strutturali, strumenti di analisi statica, ecc.

2. Il modello manca di analisi dei rischi e delle decisioni, il che impedisce che i problemi vengano rilevati prima che influenzino il processo di sviluppo.

3. L'ambito del modello non è definito, sebbene gli autori riconoscano che è universale e adatto a tutte le organizzazioni. Tuttavia, gli autori non fanno una chiara distinzione tra organizzazioni che possono o meno implementare SMM nelle loro attività. Le aziende più piccole trovano questo modello troppo burocratico. In risposta a queste critiche, sono state sviluppate strategie di miglioramento dei processi per le piccole organizzazioni.

obiettivo principale Nel creare il modello CMM, era intenzione del Dipartimento della Difesa degli Stati Uniti valutare le capacità dei fornitori di software. SU questo momento mentre non ci sono requisiti chiari per raggiungere un certo livello di sviluppo delle organizzazioni di sviluppo. Tuttavia, è generalmente accettato che un'organizzazione che ha raggiunto un livello elevato abbia maggiori probabilità di vincere una gara d'appalto per la fornitura di software. In alternativa al CMM, viene proposta una classificazione generalizzata dei processi di miglioramento della maturità tecnologica, adatta alla maggior parte delle organizzazioni e dei progetti software. Si possono distinguere diversi tipi generali di processi di miglioramento.

1. processo informale. Non ha un modello di miglioramento chiaramente definito. Può essere utilizzato con successo da un team di sviluppo separato

cov. L'informalità del processo non preclude attività formali come la gestione della configurazione, ma le attività stesse e le loro relazioni non sono predeterminate.

2. Processo gestito. Ha un modello preparato che guida il processo di miglioramento. Il modello definisce le attività, la loro pianificazione e le relazioni tra di esse.

3. Processo metodicamente corretto. Si presume che siano stati messi in atto determinati metodi (ad esempio, i metodi di progettazione orientati agli oggetti vengono applicati sistematicamente). Per questo tipo di processo saranno utili gli strumenti di supporto alla progettazione e all'analisi del processo (strumenti CASE).

4. Il processo di miglioramento diretto. Ha un obiettivo chiaramente definito di migliorare il processo tecnologico, per il quale esiste linea separata nel bilancio dell'organizzazione e definisce le norme e le procedure per l'introduzione di innovazioni. Parte di tale processo è l'analisi quantitativa del processo di miglioramento.

Questa classificazione non può essere definita chiara ed esaustiva: alcuni processi possono appartenere contemporaneamente a diversi tipi. Ad esempio, l'informalità del processo è la scelta del team di sviluppo. Lo stesso team può scegliere una metodologia di sviluppo specifica, pur avendo tutte le opportunità per il miglioramento diretto del processo. Questo processo è classificato miglioramento informale, metodicamente valido, diretto.

La necessità di questa classificazione è dovuta al fatto che fornisce la base per il miglioramento globale della tecnologia di sviluppo del software e consente all'organizzazione di scegliere diversi tipi di processi di miglioramento. Sulla fig. 1.8 mostra la relazione tra diversi tipi di sistemi software e i processi di miglioramento del loro sviluppo.

Riso. 1.8. Applicabilità dei processi di miglioramento

Conoscere il tipo di prodotto in fase di sviluppo farà la corrispondenza tra sistemi software e processi di miglioramento mostrati in Fig. 1.8 utile nella scelta del miglioramento del processo. Ad esempio, è necessario creare un programma per supportare la transizione del software da una piattaforma di computer a un'altra. Tale programma ha una durata piuttosto breve, quindi il suo sviluppo non richiede standard e amministrazione straordinaria processo di miglioramento, come nella creazione di sistemi longevi.

Molti processi tecnologici attualmente hanno il supporto CASE, quindi possono essere chiamati processi supportati. Processi metodicamente solidi sono supportati da strumenti di analisi e progettazione. L'efficacia dello strumento di supporto dipende dal processo di miglioramento applicato. Ad esempio, in un processo informale, mezzi standard supporto (strumenti di prototipazione, compilatori, strumenti di debug, elaboratori di testi, ecc.). È improbabile che strumenti di supporto più specializzati vengano utilizzati su base continuativa nei processi informali.

Il modello SMM non è unico. Quasi ogni grande azienda sviluppa le proprie tecnologie per la creazione di software, a volte queste tecnologie diventano pubblicamente disponibili e molto popolari. L'ampia popolarità del modello HMM è associata alla sua sostegno statale, ma l'effettiva efficacia dell'SMM è criticata da molti importanti esperti. Uno dei principali difetti dell'HMM è associato a un requisito inutilmente rigido di non deviare dai principi di questo modello, anche se il buon senso suggerisce diversamente. Tali pretese al possesso della verità assoluta non possono che destare sospetti, quindi, tra le piccole e medie imprese, sono più diffusi approcci che lasciano molta più libertà alla creatività individuale e collettiva. La tecnica SPMN considerata di seguito occupa una posizione intermedia tra rigida, "pesante", efficace per grandi organizzazioni soluzioni come SMM e le tecnologie più flessibili. Lei appare L'opzione migliore per le aziende che, da un lato, vogliono razionalizzare il proprio attività manageriale e, d'altra parte, hanno in programma di entrare in futuro a livello internazionale, dove la certificazione SMM è altamente desiderabile.

Nel 1982, il Dipartimento della Difesa degli Stati Uniti ha formato una commissione il cui compito principale era studiare i problemi che sorgono nello sviluppo di prodotti software nelle organizzazioni del dipartimento. Come risultato delle attività della commissione, nel dicembre 1984 è stato fondato il Software Engineering Institute (SEI) presso la Carnegie Mellon University di Pittsburgh.

1987 SEI pubblica: breve descrizione strutture CMM; metodi per valutare i processi di sviluppo del software; metodi per valutare la maturità dei processi di produzione del software; questionario per individuare il grado di maturità dei processi (per indipendenti, audizione interna e controllo esterno).

1991 Rilascio della CMM v1.0.

1992 Rilascio di CMM v1.1.

1997 Rilascio della successiva versione (migliorata) di CMM.

La metodologia CMM è stata sviluppata e sviluppata negli Stati Uniti come strumento per selezionare i migliori fornitori di software per soddisfare gli ordini governativi. Per fare ciò, avrebbe dovuto creare criteri per valutare la maturità dei processi chiave dell'azienda sviluppatrice e determinare l'insieme di azioni necessarie per il loro ulteriore miglioramento. Di conseguenza, la metodologia si è rivelata estremamente utile per la maggior parte delle aziende che cercano di migliorare qualitativamente processi esistenti progettare, sviluppare, testare strumenti software e ridurre la loro gestione ad algoritmi e tecnologie comprensibili e facilmente implementabili descritti in un unico standard.

SMM è di fatto diventato proprio uno standard di questo tipo. La sua applicazione consente di porre lo sviluppo del software su base industriale, aumentando la controllabilità dei processi chiave e la cultura della produzione in generale, garantendo un lavoro di alta qualità e l'esecuzione puntuale del progetto. La base per la creazione di CMM era la posizione di base secondo cui il problema fondamentale della "crisi" del processo di sviluppo del software di qualità non è la mancanza di nuovi metodi e strumenti di sviluppo, ma l'incapacità dell'azienda di organizzare e gestire i processi tecnologici.

Valutare la prontezza dell'impresa a sviluppare una qualità Software HMM introduce il concetto chiave maturità dell'organizzazione(Scadenza). immaturo Un'organizzazione è considerata:

• non esiste una pianificazione a lungo termine e di progetto;
• il processo di sviluppo del software e i suoi componenti chiave non sono identificati, l'implementazione del processo dipende dalle condizioni attuali, dai gestori e dagli esecutori specifici;
• metodi e procedure non sono standardizzati o documentati;
• il risultato non è predeterminato da criteri reali derivanti dagli indicatori pianificati, dall'uso di tecnologie standard e dalle metriche sviluppate;
• il processo di sviluppo di una soluzione avviene spontaneamente, sull'orlo dell'arte.

In questo caso, c'è un'alta probabilità di problemi imprevisti, superamento del budget o mancato rispetto delle scadenze del progetto. In un'azienda del genere, di norma, manager e sviluppatori non gestiscono i processi: sono costretti a occuparsi della risoluzione di problemi attuali e spontanei. Nota che su questa fase lo sviluppo è la maggior parte delle aziende russe.

Caratteristiche principali maturo organizzazioni:

• l'azienda dispone di procedure ben definite e documentate per la gestione e la pianificazione dei fabbisogni attività del progetto, gestione della configurazione, creazione e test di prodotti software, comprovati meccanismi di gestione dei progetti;
• tali procedure vengono costantemente affinate e migliorate;
• le stime di tempo, complessità e costo del lavoro si basano sull'esperienza accumulata, su metriche sviluppate e indicatori quantitativi, il che le rende abbastanza accurate;
• aggiornato esterno e creato standard interni per processi chiave e procedure;
• sono obbligatorie per tutte le regole per la progettazione del programma metodologico e della documentazione per l'utente;
• le tecnologie variano leggermente da progetto a progetto sulla base di approcci e metodologie stabili e comprovati;
• si utilizza al massimo l'esperienza organizzativa e produttiva maturata in precedenti progetti, moduli di programma, librerie software;
• le nuove tecnologie vengono attivamente testate e introdotte, la loro efficacia viene valutata.

SMM definisce cinque livelli maturità tecnologica dell'azienda, in base alla quale i clienti possono valutare potenziali candidati per un contratto e gli sviluppatori possono migliorare i processi di sviluppo del software.

Ciascuno dei livelli, ad eccezione del primo, è composto da diversi aree di processo chiave(processo chiave