La resistenza contro specifiche dei requisiti

Le prove sono sempre sarà incompleta, in modo che devono sempre essere sostenuta con altri meccanismi. Essendo la mente contorta che io sono, io in realtà vedere questo come un plus.Poiché è chiaro che Specification Per esempio non è sufficiente, è chiaro che è necessario fare di più per assicurare che tutto sia correttamente comunicati. Una delle cose più pericolose di una specifica tradizione requisiti è quando la gente pensa che una volta che hanno scritto sono fatti comunicare.

Quindi credo che è tempo di scavare la mia vecchi post  sulla documentazione . Ecco alcune cose da ricordare:

1. Documentare il comportamento del software comporta sforzo e non è libero. Come per le altre attività nello sviluppo di software, è necessario segnare il tempo per farlo. Altrimenti non sarà possibile ottenere fatto.
2. Se si alloca questa attività a qualcuno che è già assegnato altri compiti (codifica, test, ecc), è probabile che essi lo considerano una priorità inferiore rispetto ai loro altri compiti, a meno che specificamente chiede loro di non fare i loro compiti regolari e solo il lavoro il compito di documentazione.
3. Ma quando lo fate, quelle persone ancora pensano di non stanno ottenendo "lavoro" fatto. Non vi è alcun output visibile a parte un file di documentazione, e c'è meno progressi in materia di funzionalità rilasciata ai clienti, anche se ci può essere migliore qualità.
4. Aiuta ad assegnare una persona dedicata al lavoro sui requisiti, in modo che i programmatori e tester può tornare a fare quello che stanno meglio al. Uno scrittore tecnico o di un business analyst può fare un lavoro più veloce e di qualità superiore.
5. Purtroppo, questo fa lievitare il costo dello sviluppo software e potrebbe non funzionare per tutti.

L'ultimo punto è una cosa che ho trovato alcune persone non vogliono accettare. E 'meglio scrivere entrambe le specifiche buoni E scrivere buoni test, perché coprirà la maggior parte le lacune nella comprensione dei requisiti. Si potrebbe scrivere le specifiche in diversi formati per rivolgersi ad un pubblico diverso (ad esempio più grafico per i clienti e più strutturato per il tuo programmatori). Si potrebbe scrivere manuale casi di test di accettazione, di unit test automatizzati, test delle prestazioni e così via. Sono tutti utili ai margini.

Ma tutto ciò costa tempo, denaro e fatica. Se non può permetterselo, che è bene. Voi oi vostri clienti possono vivere con qualità un po 'meno. Nelle piccole squadre, questa è la realtà. Ad esempio, un piccolo team di 2 sviluppatori non avranno il tempo (e denaro) per testare a fondo ogni aspetto della loro applicazione web su tutti i browser possibili (e versioni diverse) su diversi sistemi operativi e hardware. Ma bisogna accettare il fatto che quando lo fa, arriva il rischio di errori sul campo. Alcune persone trovano questo troppo reale da gestire. Al contrario, vogliono avere (mantenere?) La botte piena e la moglie ubriaca. Vogliono liberarsi di qualcosa senza accettare che ci sia un costo per farlo.

In generale, nello sviluppo di software, software di qualità più soldi a disposizione e spesi saggiamente su persone, strumenti, infrastrutture e processi = maggiore consegnato ad un ritmo più veloce. La gente non è sempre saggio con i soldi e si può guadagnare un po 'l'efficienza con intelligenza, duro lavoro, perseveranza, e la disciplina, ma non oltre un punto. Se qualche società di software è abbastanza intelligente cento volte i soldi che hai, ci sono molte probabilità che si sta per perdere.

Corso Java - Corsi Java - Corsi programmazione Java

 Corso programmazione Android - Certificazione Android