Come possiamo verificare che il software soddisfi le specifiche e soddisfi i requisiti?

7

Quindi siamo abbastanza bravi a soddisfare i requisiti dei nostri clienti finali, divisione aziendale e vendite / marketing. Pianifichiamo progetti per aggiungere / migliorare le funzionalità per soddisfare tali richieste e dare priorità alle attività per rispettare le scadenze nell'ordine più redditizio.

Nel corso del tempo, il prodotto software è cresciuto, il mercato è cambiato ei clienti originali sono meno prioritari rispetto ad alcune nuove opportunità.

Quindi, i requisiti, e quindi le specifiche, sono cambiati, sebbene tutti i requisiti di tutte le parti interessate possano coesistere (non ci sono conflitti).

Abbiamo anche avuto una certa contrazione nel team di sviluppo con persone che si muovevano, fuori o dentro e così ora non c'è nessuno che fosse lì "all'inizio".

Ciò ha portato ad alcune interruzioni del servizio clienti in cui abbiamo rimosso quelli che sembravano percorsi di codice inutilizzati (la logica non era familiare a tutti) solo per trovare il cliente che aveva bisogno di quella logica per eseguire l'applicazione un paio di mesi dopo. p>

Sappiamo che potremmo inserire i Test unità per verificare che il comportamento non cambi in modo accidentale (come nel caso precedente), ma questo è un grande codice in modo che ci sia bisogno di tempo per testare l'unità di tutto.

Quali tecniche / tecnologie / best practice non manuali sono a nostra disposizione per verificare che il software (ancora) soddisfi le specifiche e i requisiti?

Ho sentito sostenitori agili / iterativi dire qualcosa come "I Test di unità sono le specifiche". C'è qualcosa che potremmo usare per sposare i test unitari ai requisiti originali?

Note

(Ho visto quest'altro post , ma meno sulla verifica e altro sui test di usabilità)

Facciamo già uno sviluppo iterativo, rilasciando ogni due settimane o meno.

La base di origine è per lo più C ++ su Unix. Requisiti e specifiche attualmente documentati in Wiki, Word, sistemi di ticketing e MS Project.

    
posta JBRWilkinson 12.10.2011 - 11:32
fonte

3 risposte

2

Se vuoi davvero farlo bene, devi accettare che ci sarà un sacco di lavoro manuale. Il test di unità / sistema / integrazione / regressione è vitale, ma verificherà solo che il software funzioni come richiesto dai test. La tracciabilità dei requisiti indica che ogni requisito ottiene un ID di qualche tipo e che l'ID è tracciabile durante il processo di sviluppo. Un ID requisito deve essere associato a una (o più) caratteristiche, le caratteristiche devono essere legate a un progetto e i progetti sono legati ai test. In definitiva, puoi guardare qualsiasi parte del sistema e tracciarlo avanti o indietro. Se un test fallisce, puoi vedere quali requisiti non vengono soddisfatti. Guarda un po 'di codice e vedi perché è richiesto e quali parti del sistema lo usano. Se un requisito viene eliminato, è possibile identificare quale codice e test possono essere rimossi. Sfortunatamente, non c'è un valido supporto per gli strumenti (abbiamo avuto un sacco di script Perl che collegavano FrameMaker, un sistema di gestione delle modifiche personalizzato e uno strumento di progettazione insieme).

    
risposta data 12.10.2011 - 15:30
fonte
1

Hai due cose qui: verifica e validazione. Il primo si occupa di assicurarsi che il codice corrisponda alle specifiche. Quest'ultimo si occupa di assicurarsi che il codice corrisponda alle aspettative del cliente. Lo sviluppo guidato dal comportamento e le metodologie Agile mirano a ridurre la disparità tra verifica e convalida.

La convalida può essere eseguita in termini di scenari che i tester possono eseguire. Quelli possono essere automatizzati o no. I beta tester sono una buona seconda linea in quanto i clienti possono giocare con la nuova versione. Infine, i test di accettazione degli utenti possono essere fatti e si raccomanda di appianare gli ultimi bug. Un rilascio rapido di tempo di iterazione durante questo ciclo può essere utile.

    
risposta data 12.10.2011 - 12:43
fonte
0

This has led to some customer outages where we removed what looked like unused code paths (the logic was unfamiliar to everyone) only to find the customer that needed that logic happened to run through the application a couple of months later.

Questo è strano. A meno che tu non possa provare che il codice non può mai essere eseguito (cioè è orfano), perché lo faresti?

A meno che tu non abbia un elenco documentato di tutti i requisiti, non puoi PROVE che il software soddisfi assolutamente qualsiasi cosa.

    
risposta data 12.10.2011 - 13:01
fonte

Leggi altre domande sui tag