Linea guida: Discriminanti del processo
Questa linea guida descrive i fattori che influiscono sulla personalizzazione di un processo per un progetto.
Relazioni
Descrizione principale

Panoramica

Il processo di sviluppo software è influenzato dai seguenti fattori:

  • Fattori di dominio, come il dominio dell'applicazione, il processo di business da supportare, la comunità utenti e le offerte disponibili della concorrenza.
  • Fattori del ciclo di vita, come i tempi di commercializzazione, l'estensione di vita prevista del software ed i futuri rilasci pianificati.
  • Fattori tecnici come il linguaggio di programmazione, i tool di sviluppo, il database, i framework dei componenti ed i sistemi software esistenti.
  • Fattori organizzativi.

Questi fattori non sono ugualmente importanti. Le sezioni che seguono descrivono alcuni dei principali fattori, quelli che più probabilmente influiscono sulla forma globale del processo di sviluppo, e come implementare il processo ed i tool nell'organizzazione di sviluppo.

Il contesto di business descrive il contesto in cui il software viene sviluppato.  Esistono tipi diversi di contesti di business che influiscono su come personalizzare al meglio il processo. Esempi di contesti di business sono:

  • Lavoro a contratto in cui lo sviluppatore produce il software per una specifica di un dato cliente e solo per quel cliente.
  • Sviluppo speculativo o commerciale in cui lo sviluppatore produce e copre i costi della messa sul mercato del software.
  • Progetti interni in cui il cliente e lo sviluppatore sono nella stessa organizzazione.

Esistono molte situazioni intermedie; ad esempio, quelle in cui solo parte dello sviluppo di software è subappaltato, quelle in cui la dispersione geografica è un ulteriore fattore e così via. Il numero totale di stakeholder distinti è un buon indicatore del contesto di business.

Il contesto di business influenza il livello di cerimonia, il livello di formalità e la rigidità del processo. Più stakeholder sono coinvolti (acquirenti, clienti, subappaltatori, ecc.) maggiore è la necessità per il progetto di produrre un'evidenza formale, ad esempio documenti, report e prototipi, nei principali punti cardine del progetto.

La dimensione dell'impegno lavorativo per lo sviluppo di software

La dimensione dell'impegno lavorativo per lo sviluppo del software come viene definita da determinata metrica come lo SLOC (Source Lines of Code), Delivered Source Instructions o Function Point, il numero di persone-mesi o semplicemente il costo.

La dimensione dell'impegno influirà sul livello di cerimonia, sul livello di formalità e sulla rigidità del processo. Più grande è progetto, maggiore saranno le dimensioni del team di sviluppo e, a prescindere dal contesto di business, maggiori saranno le formalità e la visibilità che i vari team ed il settore dirigenziale dovranno avere nei requisiti, nelle interfacce e negli indicatori di avanzamento. Le problematiche di comunicazione su grandi progetti sono ulteriormente aggravate dai team sparsi geograficamente.

Il grado di novità si basa su cosa ha preceduto questo impegno software relativo all'organizzazione di sviluppo ed in particolare se lo sviluppo è in un secondo ciclo o ciclo successivo. Questo include la maturità dell'organizzazione ed i suoi processi, le risorse, l'insieme corrente di skill e le problematiche come l'assemblaggio e la formazione di un team, l'acquisizione di tool ed altre risorse.

Il grado di novità di un progetto influisce sul processo in modo completamente diverso. Un progetto nuovo (il primo nel suo genere) inficia significativamente sulla configurazione dinamica: le fasi di inizio e di elaborazione saranno più lunghe e possono richiedere diverse iterazioni. Inoltre verrà posta più enfasi nel dedurre e catturare i requisiti, nella modellazione dei casi d'uso, nell'architettura e nella riduzione del rischio. Per un progetto che è un ciclo di evoluzione di un sistema precedente, la gestione delle modifiche è più cruciale e l'incorporamento del codice preesistente comporta delle sfide tecniche.

La novità non è relativa solo al sistema in fase di sviluppo, ma anche alla maturità delle organizzazioni che lo eseguono poiché l'introduzione di nuove tecniche o tool influisce sul processo. In particolare, l'introduzione di RUP (Rational Unified Process) in un'organizzazione deve essere cadenzata da attente fasi. Un'azienda esprimerà inerzia all'adozione di un nuovo processo e la strategia di adozione deve prendere in considerazione una transizione armoniosa dalle pratiche esistenti a quelle nuove.

Tipo di applicazione

Esistono diversi tipi di applicazioni, ad esempio, sistemi real-time incorporati, sistemi di informazioni distribuite, sistemi di telecomunicazione, tool CASE (Computer-Aided Software Engineering), ecc.. Il tipo di applicazione influisce sul processo, specialmente nei confronti di vincoli specifici che il dominio può imporre sullo sviluppo, come la sicurezza, le prestazioni, l'internazionalizzazione, i vincoli di memoria, e così via.

Il tipo di applicazione può influire sul processo se l'applicazione è critica per la missione; ad esempio, il sistema di controllo di volo in un aeroplano. Un sistema con missione critica richiede un livello superiore di cerimonia in generale, sia per tracciare i requisiti che per garantire la qualità del prodotto. Un'applicazione con missione critica richiede anche che siano impiegate più risorse per la verifica.

Il tipo di sviluppo o il dominio di destinazione, porta problematiche nel processo, ad esempio:

  • Tecniche e tool per supportare delle attività specifiche; ad esempio, la creazione di codice automatica per le macchine FSM (finite-state machine, macchine a stati finiti).
  • Procedure di certificazione; ad esempio, per la strumentazione medica.
  • Conformità con gli standard; ad esempio, per problematiche di contabilità o fiscali, e per attrezzature di telecomunicazione.

Tipo di sviluppo

Esistono vari tipi di sviluppo, come:

  • Lavoro a contratto, in cui viene sviluppato un prodotto per un cliente specifico. Quando si esegue un lavoro a contratto ci sono più stakeholder da gestire e con cui negoziare. Spesso esiste l'esigenza di prodotti di lavoro più formali esterni perché il cliente, o i rappresentanti, desiderano monitorare l'avanzamento ed essere informati. I prodotti di lavoro che il cliente deve revisionare devono essere di semplice comprensione. A volte, nasce l'esigenza di avere un punto cardine in cui il progetto può offrire un prezzo fisso sul resto del progetto. In questo caso potrebbe essere necessario aggiungere un punto cardine o adattare quelli esistenti. In altri casi potrebbe essere necessario adattarsi al modello di ciclo di vita che utilizza il cliente con altri punti cardine e fasi.
  • Sviluppo speculativo, in cui viene sviluppato un prodotto per il mercato di massa. Nello sviluppo speculativo, un responsabile del marketing (prodotto) all'interno dell'organizzazione stessa, agisce da cliente. I tempi di commercializzazione spesso sono più importanti della funzionalità nello sviluppo speculativo e l'esigenza di revisioni formali è minore.
  • Sviluppo interno, in cui viene sviluppato un prodotto che viene distribuito in un altro reparto all'interno di un'azienda. Potrebbe essere necessario adattarsi ad un altro modello di ciclo di vita, se si distribuisce per un altro progetto che non utilizza RUP. Potrebbe essere accettabile essere più tecnici quando si descrivono i prodotti di lavoro perché la maggior parte di essi verrà revisionata da colleghi.
  • Pre-studio, in cui normalmente non viene sviluppato un prodotto. Lo scopo di un progetto di pre-studio è scoprire se è possibile creare un prodotto. Un progetto pre-studio non dispone degli stessi punti cardine di un normale progetto.

Il processo di sviluppo corrente

Nella maggior parte dei casi non si sostituisce il processo di sviluppo software attivo al momento nell'organizzazione perché piuttosto si implementa il nuovo processo di sviluppo passo dopo passo, concentrando l'attenzione prima sulle aree più critiche ed importanti. Parte del corrente processo di sviluppo software può anche continuare ad esistere per un po' di tempo, forse per sempre.

Problemi e cause principali

I problemi che vengono identificati e a cui viene assegnata una priorità per il progetto influenzano le aree del processo in cui si concentra l'attenzione all'inizio dell'implementazione del processo. E' importante notare che, se non è stata stabilita una metodologia di lavoro nell'organizzazione, non ha senso rilevare i problemi. Consultare Concetto: Implementazione di un processo in un progetto. Potrebbe essere necessario, invece, identificare le cause principali dei problemi. Per eliminare i problemi, si affrontano le cause di origine migliorando il relativo processo, introducendo i tool per automatizzare il processo e formando le persone. 

Esempi di problemi comuni

Quelli che seguono sono gli esempi di alcuni dei problemi comuni:

  • Incapacità di gestire l'ambito; l'organizzazione tenta di routine di eseguire più di quanto in realtà svolga alla fine.
  • Incapacità di catturare i requisiti; hanno difficoltà a specificare i requisiti.
  • Incapacità di gestire i requisiti che mutano.
  • Incapacità di gestire i requisiti; i requisiti non arrivano al prodotto finale.
  • Incapacità di stimare; sono di routine troppo ottimisti sulla loro abilità nel distribuire il prodotto secondo i tempi previsti.
  • Carenza di progettazione; sono validi nel soddisfare i requisiti ma scarsi nella progettazione di sistemi. Che tipo di problemi di progettazione hanno? I sistemi sono difficili da gestire e da migliorare? Hanno problemi di prestazione, di utilizzabilità, di capacità, ecc. ?
  • Incapacità di produrre prodotti di qualità; il prodotto ha troppi difetti che possono essere dovuti a mancanza di test ma in genere è correlato anche all'incapacità di catturare e gestire i requisiti, oltre alla carenza di progettazione.
  • Prestazioni software inaccettabili.
  • Bassa utilizzabilità.
  • Sviluppatori in conflitto; esiste una mancanza di controllo sulla proprietà e la gestione della configurazione, e gli sviluppatori apportano modifiche che entrano in conflitto, con conseguente perdita del lavoro.
  • Rilevazione tardiva di problemi. 
  • Problematica che va dai casi d'uso alla progettazione.
Esempi di cause principali

Un problema spesso è sintomo di qualcosa che non va. È necessario identificare le cause principali dei problemi. Quelli che seguono sono degli esempi di cause comuni:  

  • Gestione dei requisiti insufficiente
  • Comunicazioni ambigue ed imprecise
  • Architettura instabile
  • Complessità preponderante
  • Incongruenze non rilevate nei requisiti, nelle progettazioni e nelle implementazioni
  • Verifica insufficiente
  • Valutazione soggettiva dello stato del progetto
  • Riduzione del rischio ritardata a causa dello sviluppo a cascata
  • Diffusione non controllata delle modifiche
  • Automazione insufficiente
  • Metodo di creazione delle interfacce utente non sistematico
  • Nessun modo per passare dai casi d'uso ad una progettazione

Fattori organizzativi

L'implementazione del processo in un'organizzazione dipende da fattori organizzativi quali la capacità dell'organizzazione relativa alla modifica, alla struttura organizzativa, alla cultura dell'organizzazione e della gestione del progetto, alle competenze e skill disponibili, alle esperienze precedenti e atteggiamenti correnti.

I fattori organizzativi influenzano anche il modo in cui viene configurato il processo. Ad esempio, se le persone dell'organizzazione hanno utilizzato in precedenza una descrizione del processo di sviluppo software, sarà più semplice iniziare ad utilizzare RUP. D'altro canto, se le persone non hanno utilizzato una descrizione del processo di sviluppo software, si può decidere di limitare l'ambito della descrizione del processo. E' possibile anche mettere ulteriore impegno nel rendere la descrizione del processo facile da capire e da utilizzare, accertandosi che includa (o vi faccia riferimento) le informazioni che forniscono il valore maggiore.

Se sono presenti alcune aree nuove per molte persone, lo sviluppo delle migliori linee guida possibile rende la transizione più semplice. Ad esempio, se il linguaggio di programmazione è nuovo a molte persone, è auspicabile disporre di ottime linee guida di programmazione e di progettazione utili per l'apprendimento.

Atteggiamenti

Gli atteggiamenti negativi fra il personale dell'organizzazione nei confronti del passaggio ad una nuova tecnologia, ad un nuovo processo o nuovi tool probabilmente sono la più grande minaccia contro un'implementazione di successo del processo e dei tool. Anche un entusiasmo sopra le righe può essere un problema perché può portare le persone a concentrare troppo l'attenzione sul processo.

Per valutare l'atteggiamento delle persone nei confronti della nuova tecnologia, processo e tool, porre questo genere di domande:

  • Quali vantaggi porta la nuova tecnologia? La nuova tecnologia risolverà qualcuno degli attuali problemi? Quali problemi comporta la nuova tecnologia?
  • Quali vantaggi porta il nuovo processo? Il nuovo processo risolverà qualcuno degli attuali problemi? Quali problemi comporta il nuovo processo?
  • Quali vantaggi portano i nuovi tool? I nuovi tool risolveranno qualcuno degli attuali problemi? Quali problemi comportano i nuovi tool?

Per valutare la motivazione delle persone, porre questo genere di domande:

  • Tutti nell'organizzazione vedono le motivazioni di questo cambiamento?
  • Sono tutti al corrente delle conseguenze della competizione e come questa influenzi il business?
  • Sono tutti al corrente sulle modifiche tecnologiche nell'industria e come influenzano il business?  

Segnali di un atteggiamento negativo possono includere affermazioni quali:

  • "Il processo non è utile, ostacola".
  • "Il processo significa produrre molti documenti".
  • "Il processo è opprimente".

Alcuni metodi per gestire gli atteggiamenti negativi sono:

  • Motivare le persone indicando i problemi attuali.
  • Spiegare che un processo non detta quello che si deve svolgere. Il processo deve essere visto principalmente come un "sistema utile", in cui si cerca una guida, delle definizioni, e così via.
  • Spiegare che la persona utilizzerà solo una piccole sezioni del processo. Nessuno può diventare esperto dell'intero processo, e quello non è il suo scopo. Paragonare il processo ad uno scaffale di libri che si consultano quando sono necessarie le informazioni.
  • Eseguire un progetto pilota riuscito in cui dimostrare che il nuovo processo ed i nuovi tool funzionano. Includere nel progetto pilota uno o due scettici. 

Segnali di esagerato entusiasmo includono:

  • Persone che si appoggiano completamente sul processo e pensano che risolverà tutti i loro problemi.
  • Il processo è la pallottola d'argento o la formula magica che, se seguita, garantisce il successo.
  • Il team del progetto desidera passare molto tempo ed impegno nel personalizzare il processo senza prima valutare i problemi correlati al processo che necessitano di risoluzione.  

Alcuni metodi per gestire gli eccessivi entusiasmi sono:

  • Impostare delle aspettative. Il processo aiuta ma non risolve i problemi. Sono le persone che li risolvono.
  • Dissuadere le persone dal passare molto tempo a personalizzare il processo.
  • Focalizzare le persone sullo sviluppo di prodotti software.

Differenti tipi di sistemi, ed i relativi progetti, possono essere classificati in termini di complessità tecnica del sistema e di complessità manageriale. La figura che segue illustra un concetto di come possono essere classificati i sistemi differenti. Ad esempio, una tipica piccola applicazione di business a foglio elettronico spesso è poco complessa e facile da gestire. L'altro estremo è un tipico progetto di sistema di armamenti, che spesso è complesso sia tecnicamente che da gestire.

In genere anche l'aumento delle dimensioni del sistema, la durata del progetto o il contesto di business aumentano la complessità manageriale. Aumentando la novità nel dominio del problema o nello spazio della soluzione aumenta la complessità tecnica. Esiste un'interazione fra la complessità manageriale e quella tecnica; molti grossi progetti sono anche complessi tecnicamente. Questo comporta:

  • Aumentata complessità manageriale che porta a più cerimonia, incluso più revisioni formali e punti cardine e più prodotti di lavoro.
  • Aumentata complessità tecnica che porta all'introduzione di tecniche specifiche, ruoli e tool, e quindi più attività.

Diagramma descritto nel testo di accompagnamento.

I sistemi sono classificati in termini di complessità tecnica e manageriale