Prodotti software. Modelli di maturità del processo di test di SMM Software System Design Maturity Model

05.04.2007 Vyacheslav Pankratov

Oggi si parla molto di qualità. Software e sistemi informativi, 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 identici sistemi software, e ancora di più, non esistono due team di sviluppo identici in termini di 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 (Capacità Maturità Model for Software, CMM), che è stato successivamente sviluppato in CMMI (Capability Maturity Model Integration), un certificato de facto di livello di maturità del processo di 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 sono diventati popolari principalmente per la loro semplicità, nonché per le pratiche proposte. audit interni, che può essere prodotto 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 nel ciclo di vita dello sviluppo del 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 livello superiore - è impegnato con i compiti di revisioni critiche del codice, ci 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 si tratta della qualità ideale del prodotto rilasciato o della completa assenza di difetti: si tratta di fiducia nello stato della versione rilasciata, sia da parte del team di progettazione che da parte 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 di supporto tecnico, che possono confermare le positive dinamiche di miglioramento del livello qualitativo 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).

Prenderemo in considerazione l'evoluzione dei modelli di garanzia della qualità sulla base del "modello di maturità del processo", o "modello di miglioramento della capacità" CMM (Capability Maturity Model). Anche se il modello SMMè finalizzato a garantire la qualità del software, i suoi aspetti metodologici sono applicabili a modelli per garantire la qualità di qualsiasi prodotto (beni, opere, servizi).

Principale nel modello SMMè il concetto di maturità organizzativa.

immaturoè considerata un'organizzazione in cui il processo di sviluppo del software dipende solo da specifici esecutori e manager e le decisioni vengono spesso prese "al volo". In questo caso, c'è un'alta probabilità di superare il budget o di non consegnare il progetto, e quindi i manager sono costretti a occuparsi solo della risoluzione dei problemi immediati.

Maturo Si ritiene che un'organizzazione soddisfi le seguenti condizioni:

• – esistono procedure ben definite per la creazione di prodotti software e la gestione dei progetti, che vengono affinate e migliorate progetti pilota analizzando le componenti di "costo - profitto";
• – le stime dei tempi e dei costi di esecuzione del lavoro si basano sull'esperienza accumulata e sono quindi abbastanza accurate;
• – l'azienda dispone di standard per i processi di sviluppo, test e implementazione del software, regole per la progettazione del codice finale del programma, componenti, interfacce, ecc. Tutto ciò costituisce l'infrastruttura e la cultura aziendale che supporta il processo di sviluppo del software.

Quindi la norma SMMè un modello di garanzia della qualità che consiste in criteri per valutare la maturità di un'organizzazione e ricette per il miglioramento processi esistenti. Nel modello SMM sono definiti cinque livelli di maturità delle organizzazioni, le cui caratteristiche sono presentate in fig. 5.3.

Riso. 5.3. Cinque livelli di maturità del modelloSMM

Primo livello (livello iniziale)è la base per lo sviluppo dell'impresa ai seguenti livelli. Si ritiene che nell'impresa entry-level dell'organizzazione non vi siano condizioni stabili per la creazione di software di alta qualità. Di conseguenza, il risultato di qualsiasi progetto dipende interamente dalle qualità personali del manager e dall'esperienza dei programmatori. Ciò significa che il successo in un progetto può essere ripetuto solo se gli stessi manager e programmatori vengono assegnati al progetto successivo. Se, tuttavia, manager o programmatori che hanno acquisito esperienza nei progetti lasciano l'impresa, la qualità del software prodotto diminuisce drasticamente con la loro partenza.

Va riconosciuto che a livello iniziale, in situazioni stressanti di elevata dipendenza dal fattore umano, il processo di sviluppo si riduce alla scrittura di codice e test minimi.

Raggiungere il secondo livello ripetibile (livello ripetibile) è determinato dall'implementazione della tecnologia di gestione dei progetti nell'impresa. La pianificazione e la gestione dei progetti nell'azienda si basano sull'esperienza accumulata, esistono e vengono utilizzati standard per il software sviluppato, la cui conformità è controllata da uno speciale gruppo di garanzia della qualità. Si ritiene che il secondo livello possa sia fornire opportunità di ulteriore miglioramento (transizione al terzo livello), sia non escludere la possibilità di un ritorno regressivo della qualità del processo di sviluppo del software al livello iniziale in condizioni critiche.

Terzo, un certo livello (definito a sinistra) caratterizzato dal fatto che il processo standard di creazione e manutenzione del software è completamente documentato, dallo sviluppo del software alla gestione del progetto. L'ipotesi di introdurre questo livello è che nel processo di standardizzazione ci sia una transizione dell'impresa al massimo pratiche efficaci e tecnologia. Per creare e mantenere il funzionamento degli standard per lo sviluppo del software e la gestione dei progetti in un'organizzazione, dovrebbe essere creato un gruppo speciale. Un prerequisito per raggiungere il terzo livello è la presenza in azienda di un programma di sviluppo professionale continuo e formazione dei dipendenti. Si ritiene che a partire da questo livello l'organizzazione cessi di dipendere dalle qualità di specifici sviluppatori e non tenda a scivolare a un livello inferiore in situazioni di stress.

Al quarto, livello gestito (livello gestito) l'impresa stabilisce indicatori quantitativi di qualità, sia per i prodotti software che per i processi della loro creazione in generale. Pertanto, si ottiene una migliore gestione del progetto riducendo le deviazioni di vari indicatori di progetto. Allo stesso tempo, le variazioni significative (di segnale) dei processi di sviluppo software implementati e le variazioni casuali (di rumore) del processo vengono separate.

Quinto (il più alto), livello di ottimizzazione (livello di ottimizzazione) caratterizzato dal fatto che le misure di miglioramento vengono applicate non solo ai processi esistenti, ma anche per valutare l'efficacia dell'introduzione di nuove tecnologie. Il compito principale dell'impresa a questo livello è il miglioramento continuo dei processi esistenti. Allo stesso tempo, il miglioramento del processo dovrebbe contribuire alla prevenzione di possibili errori e difetti. Allo stesso tempo, è necessario lavorare per ridurre i costi di sviluppo del software.

Annotazione: La gamma di idee alla base della metodologia probabilmente più nota per migliorare i processi di sviluppo del software, CMM, è studiata in dettaglio. Viene analizzata la logica e la struttura dell'HMM. Viene mostrata la connessione tra l'HMM ei modelli di processo precedentemente studiati.

Meraviglioso strumento pratico creato all'interno del quadro approccio processuale alla descrizione dell'attività organizzazione progettuale in particolare, l'organizzazione che si sviluppa Sistemi di informazione , dimostra la metodologia HMM. CMM è l'acronimo di Capability Maturity Model, che significa approssimativamente "modello di maturità del sistema di gestione". In letteratura, il CMM è più comunemente indicato come un modello di maturità organizzativa, e seguirò anche quella tradizione.

La storia dell'emergere di SMM è la seguente. Alla fine degli anni '80. il secolo scorso, il Dipartimento della Difesa degli Stati Uniti ha ordinato all'Institute of Software Engineering 1Eng. SEI - Istituto di Ingegneria del Software La Carnegie Mellon University sta lavorando a un sistema di criteri per la selezione dei subappaltatori nei progetti di sviluppo software. Il lavoro fu completato nel 1991 e il risultato fu la CMM. Dobbiamo immediatamente fare una riserva che il modello non contenga alcun elemento finanziario, economico, politico, organizzativo criteri di selezione subappaltatore, nonché i criteri per la possibilità di ammissione al lavoro segreto (probabilmente tali compiti non erano fissati). Riguarda solo sui criteri che descrivono la capacità di un potenziale subappaltatore in termini di sviluppo di sistemi software.

Struttura CMM

I creatori del modello hanno preso i processi dell'organizzazione come base per valutare la capacità di un'organizzazione di svolgere un lavoro di qualità, che (capacità) era chiamata maturità. Quindi hanno formulato alcune ipotesi non banali, che sono state successivamente accettate e riconosciute come giuste da molti professionisti IT (e forse dalla maggior parte di loro).

Presupposto 1. Ci sono livelli qualitativamente diversi di maturità organizzazione progettuale sviluppando Sistemi di informazione(ci sono cinque di questi livelli nel modello HMM).

Ipotesi 2. Qualsiasi organizzazione di sviluppo è interessata a passare a un livello di maturità più elevato (non solo per aumentare le proprie possibilità nella lotta per i contratti del Dipartimento della Difesa, ma anche per migliorarsi).

Ipotesi 3. La transizione è possibile solo al livello successivo in ordine. È impossibile "saltare" oltre il livello (più precisamente, i rischi per l'organizzazione aumentano notevolmente allo stesso tempo).

Pertanto, i livelli formano una "scala" lungo la quale l'organizzazione sale man mano che si sviluppa. Ogni livello è caratterizzato da una certa composizione e proprietà dei processi dell'organizzazione. La SMM "Level Ladder" è stata ampiamente accettata e diffusa. Ecco come appare.

Livello 1 "Principiante". Il processo produttivo nel suo complesso si caratterizza per essere creato ogni volta per un progetto specifico, e talvolta anche come caotico. Sono definiti solo pochi processi e il successo del progetto dipende dagli sforzi dei singoli.

Livello 2 "Ripetibile". Sono stati stabiliti i principali processi di gestione del progetto, che consentono di tenere traccia dei costi, monitorare il programma di lavoro e la funzionalità della soluzione software che si sta creando. Stabilito la disciplina di processo necessaria per replicare i successi passati in progetti di sviluppo di applicazioni simili.

Livello 3 "Definitivo". Il processo di produzione è documentato e standardizzato sia per la gestione che per l'ingegneria. Questo processo è integrato nel processo di produzione standard dell'organizzazione. Tutti i progetti utilizzano una versione personalizzata approvata del processo operativo standard dell'organizzazione.

Livello 4 "Gestito". Vengono raccolti indicatori quantitativi dettagliati del processo produttivo e della qualità del prodotto che si sta realizzando. Sia il processo produttivo che i prodotti sono valutati e controllati da un punto di vista quantitativo.

Livello 5 "Ottimizzazione". Il miglioramento continuo del processo si ottiene attraverso il quantitativo feedback con il processo e l'implementazione di idee e tecnologie avanzate in esso.

Nonostante la mancanza di rigore, la definizione di cui sopra intuitivamente il più delle volte non solleva obiezioni. Inoltre, specialisti esperti comprendono perché le transizioni sono possibili solo al livello successivo, nonché perché vale la pena lottare per una tale transizione. Allo stesso tempo, il modello HMM non contiene alcuna prova quantitativa o anche formale di tale approccio, il che, tuttavia, non ne pregiudica i meriti.

Inoltre, come si suol dire, è una questione di tecnologia. Viene definita la struttura del modello (Figura 7.1), vengono fornite le definizioni e inizia un lavoro scrupoloso per descrivere accuratamente ogni processo a ciascun livello. Per valutare il valore pratico di quanto fatto, ripercorriamo parte di questo percorso.

Riso. 7.1.

Sulla fig. 7.1 contiene i seguenti concetti.

Gruppo processi chiave . Come affermato in (Paulk, et al., 1995), "ogni gruppo di processi chiave definisce un blocco lavori correlati, a seguito del quale si raggiunge una serie di obiettivi significativi per aumentare la produttività del processo produttivo. Ad esempio, per un gruppo di processi chiave " Gestione dei requisiti"(Vedi Figura 7.2) l'obiettivo è riconciliare i requisiti del progetto di sviluppo software tra il cliente e lo sviluppatore."

Non ci sono singoli processi nel CMM. Invece ci sono singole opere, chiamate pratiche chiave (vedi sotto), collegate tra loro da input e output e che servono come materiale di partenza per i processi di costruzione. Il CMM non fornisce indicazioni su come dovrebbero essere strutturati i processi, ad esempio collegando le pratiche chiave in sequenze logiche. Gli insiemi di pratiche chiave sono chiamati gruppi di processi chiave.

Riso. 7.2.

I gruppi di processi chiave nel CMM sono mappati ai livelli di maturità (Figura 7.2), ovvero tutte le pratiche a un livello interagiscono solo tra loro e non interagiscono con le pratiche ad altri livelli. Ciò consente di garantire la piena prestazione di tutti i processi a un livello specifico e, quindi, correlare il livello con la fase completata dello sviluppo dell'organizzazione.

L'aggettivo "chiave" implica che ci siano gruppi di processo(vale a dire, insiemi di pratiche) che non sono fondamentali in termini di uno specifico livello di maturità, vale a dire, non correlate al raggiungimento degli obiettivi di questo livello (vedi sotto). Il modello HMM non descrive tutto gruppi di processo relativi allo sviluppo e alla manutenzione del software . Descrive solo quei gruppi che sono identificati come determinanti chiave della produttività del processo produttivo.

Obiettivi. Gli obiettivi in ​​CMM non sono associati ai processi, ma a gruppi di processi chiave. Come accennato in precedenza, gli obiettivi vengono raggiunti attraverso l'implementazione di pratiche chiave. In CMM, raggiungere l'obiettivo significa che, in primo luogo, dopo l'implementazione delle pratiche chiave, si ottiene il risultato desiderato e, in secondo luogo, si ottiene in modo abbastanza coerente. Il modo in cui vengono raggiunti gli obiettivi del Key Process Group può variare da progetto a progetto a causa delle differenze di argomento o ambiente.

Se questi obiettivi vengono realizzati per tutti i progetti, ciò significa che l'organizzazione ha raggiunto il livello di maturità del processo di produzione, che è correlato a questo gruppo di processi chiave.

Capitolo. Le sezioni (ce ne sono cinque per ogni livello e sono sempre le stesse) rappresentano le proprietà di gruppi di processi chiave che devono essere implementati al livello corrispondente. Queste proprietà descrivono come i processi sono implementati e in che misura sono legalizzati nell'organizzazione, cioè ufficialmente approvati e coordinati con procedure, politiche e altri processi aziendali. Ecco le cinque sezioni.

Obblighi di prestazione

Descrivere le azioni che l'organizzazione deve intraprendere per garantire che il processo sia stabilito e stabile. Gli obblighi di prestazione riguardano tipicamente la definizione di politiche organizzative e il supporto dell'alta direzione.

Prerequisiti

Descrivere i prerequisiti che devono essere soddisfatti in un progetto o in un'organizzazione per l'attuazione competente di un processo di fabbricazione; di solito si riferiscono a risorse, strutture organizzative e formazione richiesta.

Operazioni in corso

La sezione Operazioni in corso descrive il lavoro sostanziale che deve essere svolto a questo livello. Le operazioni eseguite in genere includono la creazione di piani e l'implementazione di operazioni specifiche, l'esecuzione e il monitoraggio del lavoro e l'adozione di azioni correttive secondo necessità.

Misure e analisi

Sezione "Misure e

"Ogni gruppo di processi chiave è espresso da pratiche chiave, la cui implementazione contribuisce al raggiungimento degli obiettivi del gruppo. Le pratiche chiave descrivono l'infrastruttura e le operazioni che contribuiscono maggiormente all'effettiva implementazione e costituzione di un gruppo di processi chiave.

Ogni pratica chiave consiste in una singola frase, spesso seguita da una descrizione più dettagliata che può includere esempi e chiarimenti. Le pratiche chiave, a volte denominate pratiche chiave di livello superiore, stabiliscono le politiche, le procedure e le operazioni di base per un gruppo di processi chiave. Componenti descrizione dettagliata spesso indicato come sub-pratiche."

Le pratiche chiave descrivono COSA deve essere fatto, ma non dovrebbero essere prese come dogmi su COME gli obiettivi dovrebbero essere raggiunti. Gli obiettivi del gruppo di processi chiave possono essere raggiunti attraverso pratiche alternative. L'interpretazione delle pratiche chiave dovrebbe essere ragionevole, consentendo di raggiungere gli obiettivi del gruppo di processi chiave in modo efficiente, anche se forse formalmente e diversamente dal CMM raccomandato.

Uno sguardo alle attività di gestione IT, in cui, invece dei processi, vengono considerati i loro componenti: pratiche chiave ei processi sono presenti solo virtualmente, come qualcosa che può essere costruito da pratiche chiave, a prima vista sembra alquanto esotico. Fino ad ora, il compito di migliorare la gestione IT è stato risolto con l'introduzione di processi già pronti dal modello di processo di riferimento. Ora c'è una serie di livelli contenenti pratiche chiave disparate (cioè non integrate nei processi) e una sequenza consigliata per spostarsi attraverso i livelli. La gestione IT, secondo CMM, migliora man mano che passa a un livello di maturità più elevato. Cosa succede con questa promozione?

Nelle definizioni dei livelli (vedi Figura 7.2), è apparso qualcosa come un "processo di produzione". È presente anche nella definizione di un gruppo di processi chiave, e non è un caso. Il processo di produzione, o come viene giustamente chiamato in CMM, lo Standard Processo di fabbricazione Organizzazioni (OSS) è uno dei concetti centrali dell'intero modello.

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; chiaramente non ci sono abbastanza specialisti sul mercato del lavoro con le qualifiche necessarie. 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 coinvolti 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 SMM è fornire alle organizzazioni di sviluppatori istruzioni necessarie sulla scelta di una strategia per il miglioramento della 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 compongono 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 a causa del fatto che 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 dei 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 su progetti pilota e conferendo loro lo status di standard di impresa.

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. È possibile identificarne diversi tipi comuni 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 riga 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

Conoscendo la tipologia di prodotto in fase di sviluppo si effettuerà la corrispondenza tra sistemi software e processi di miglioramento mostrata 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.

La qualità dei prodotti software è forse uno dei problemi più seri nell'industria del software. La qualità è molto più della semplice assenza di errori. Implica un insieme di caratteristiche diverse: affidabilità, hackerabilità, adattabilità, compatibilità, manutenibilità, portabilità, efficienza e così via.Non sorprende che ci sia una tale varietà di standard di qualità nell'industria del software.

La qualità era facile da misurare: o venivamo pagati o no.
Dean Leffingwell, Don Widrig.
Gestione dei requisiti software

CM/CMMI

Forse lo standard di qualità più famoso dovrebbe essere considerato il Capability Maturity Model (CMM), un modello per valutare il livello di maturità dei processi di sviluppo insieme ai suoi derivati. È stato creato dal SEI (Software Engineering Institute), che è finanziato dal Dipartimento della Difesa degli Stati Uniti ed è un'unità strutturale della Carnegie Mellon University. Primo versione ufficiale standard è stato pubblicato nel 1993, sebbene i lavori su di esso siano iniziati molto prima: le sue disposizioni principali sono state pubblicate già nel 1986.

Il successo di CMM è stato predeterminato da diversi fattori. Questo standard è stato uno dei primi, inizialmente tenendo conto delle specificità dello sviluppo del software. Si è rivelato abbastanza semplice e trasparente sia per la comprensione che per l'uso, e regolava "cosa" e non "come" fare, e quindi era adatto a varie metodologie di sviluppo e non imponeva alcuna restrizione su standard di documentazione, strumenti, ambiente e linguaggi utilizzati nei progetti. E, forse, il fattore principale che ha predeterminato la popolarità di CMM è stata la collaborazione di SEI con il Dipartimento della Difesa degli Stati Uniti, che di fatto ha significato l'uso dello standard nell'attuazione di progetti commissionati da questo dipartimento.

Il modello CMM (Tabella 1) prevede cinque livelli di maturità, ognuno dei quali corrisponde ad alcune aree chiave di processo (Key Process Areas, KPA).

Tabella 1. Livelli del modello CMM

numero di livello	Nome del livello	Aree di processo chiave
1	Elementare	Se l'organizzazione è a questo livello, non ci sono aree di processo chiave per essa
2	ricorrente	Gestione della configurazione del software Garanzia della qualità del prodotto software Gestione dei contratti degli appaltatori Monitoraggio dell'avanzamento del progetto Pianificazione del progetto software Gestione dei requisiti
3	Definito	Valutazioni di esperti.Coordinamento delle interazioni tra i team di progetto.Ingegneria del prodotto software.Gestione completa del software.Programma di formazione del personale.Definizione del processo organizzativo.Ambito del processo organizzativo
4	Gestito	Gestione della qualità del software Gestione dei processi basata su metodi quantitativi
5	ottimizzabile	Gestione del cambiamento di processo.Gestione del cambiamento tecnologico.Prevenzione dei difetti

La suddivisione in livelli e la definizione di KPA per ciascuno di essi consente l'implementazione coerente del CMM, utilizzando lo standard come guida, che può garantire un miglioramento continuo nel processo di sviluppo.

Lo standard CMM si è rivelato molto efficace e successivamente è stata creata un'intera serie di standard sulla sua base (Tabella 2). Inoltre, ha ricevuto un nuovo nome: SW-CMM (Capability Maturity Model for Software), che riflette più accuratamente la sua posizione in una famiglia di standard piuttosto ampia.

Tabella 2. Sviluppo degli standard CMM

Nome della norma	Descrizione
CMM per ingegneria di sistema (SE-CMM)	Si concentra su questioni di ingegneria dei sistemi: sviluppo del prodotto (analisi dei requisiti, progettazione e integrazione dei sistemi di prodotto) e loro produzione (pianificazione e funzionamento della linea di produzione)
CMM affidabile (T-CMM)	Progettato per servire sistemi software sensibili e chiusi che richiedono software assurance di alta qualità
CMM per l'ingegneria della sicurezza dei sistemi (SSE-CMM)	Si concentra sugli aspetti di sicurezza dell'ingegneria del software, garantisce un processo di sviluppo sicuro, inclusa la sicurezza dei membri del team di creazione
Persone CMM (P-CMM)	Considera i problemi dello sviluppo del personale nelle organizzazioni di software
CMM di acquisizione software (SA-CMM)	Copre l'acquisizione di prodotti software da organizzazioni esterne
CMM per lo sviluppo prodotto integrato (IPD-CMM)	Funge da struttura per l'integrazione degli sforzi di sviluppo in tutte le fasi ciclo vitale e da ogni reparto dell'azienda

Tuttavia, l'applicazione pratica degli standard della serie CMM ha dimostrato che non forniscono un successo incondizionato nello sviluppo del software. Questi standard non erano ben coordinati tra loro: l'implementazione simultanea di varie modifiche del CMM poteva essere una vera sfida e sconcertare gli specialisti delle organizzazioni che l'hanno affrontata.

Inoltre, un problema significativo di CMM è la necessità di "allineare" tutti i processi. Se un'organizzazione sta tentando di certificare a un certo livello, deve garantire che il livello appropriato sia applicato a tutti i suoi processi. Anche se le specifiche, la metodologia o le caratteristiche di sviluppo non hanno determinati processi da eseguire, la certificazione lo richiede.

Un altro problema è causato dalla posizione che gli standard CMM hanno assunto nella moderna industria del software. Poiché un'organizzazione con un livello elevato in conformità con il CMM deve fornire prestazioni del prodotto software superiori rispetto a quelle certificate a livelli inferiori, lo standard è stato utilizzato come criterio di selezione per la partecipazione a gare per lo sviluppo di software o progetti di outsourcing. La richiesta di organizzazioni certificate ha dato vita a una proposta di "certificazione rapida e indolore".

Questa situazione è diventata possibile a causa delle carenze del processo di certificazione. Non l'intera organizzazione nel suo insieme è soggetta a certificazione, ma solo un progetto specifico. Nulla impedisce a un'organizzazione di creare un progetto "dimostrativo" che soddisfi tutti i requisiti degli alti livelli dello standard CMM, ottenere il livello di certificazione appropriato e dichiarare che tutti i prodotti soddisfano questo o quel livello dello standard.

Risolvi la maggior parte dei problemi CMM è progettato nuova norma SEI - Capability Maturity Model Integrated (CMMI) - Modello integrato per la valutazione del livello di maturità dei processi di sviluppo. Lo standard CMMI è stato originariamente creato in modo tale da combinare le varianti esistenti del CMM ed eliminare eventuali contraddizioni nella sua implementazione. applicazione pratica v vari campi attività delle imprese ad alta tecnologia.

Al fine di eliminare la necessità di "allineare" i processi dell'organizzazione ed essere più adattati alle sue esigenze aziendali, e non viceversa, lo standard CMMI ha due forme di presentazione: il classico, multilivello, corrispondente al CMM, e il nuovo, continuo. La forma continua di presentazione considera non i livelli di maturità (Maturity Levels), ma i livelli di opportunità (Capability Levels), che vengono valutati per singole aree processi (Aree di Processo, PA). A tavola. 3 fornisce una mappatura dei livelli di maturità dello standard CMM, nonché dei livelli di maturità della presentazione CMMI stratificata e dei livelli di capacità della presentazione CMMI continua.

SEI si sta allontanando dal CMM e in cambio promuove attivamente il CMMI, promettendo di rafforzare il controllo sul processo di certificazione, introducendo nuove classi per ridurre i costi e renderlo più attraente per le organizzazioni più piccole; garantendo la compatibilità con Norme ISO. Tuttavia, resta il fatto che in condizioni moderne la presenza di un certificato di un certo livello di CMM / CMMI non è un fattore così significativo come lo era diversi anni fa, ed è accettata senza ulteriori domande, tranne forse in progetti realizzati per ordine del governo.