Il portale italiano non è più aggiornato. Si prega di accedere al contenuto in inglese o spagnolo

10 principi di ispezione continua

Cos'è l'ispezione continua?

Facciamo un po’ di memoria. La ispezione continua è un nuovo paradigma nella gestione della qualità del codice progettato per rendere la qualità del software qualcosa di interno all’azienda, una parte integrale del ciclo di vita dello sviluppo del software. L’ispezione continua gode di una base di adozione tra i team di sviluppo, perché la sua natura collaborativa porta a una proprietà del codice veramente collettiva e aiuta i team a fornire un software migliore.

Fornisce una gestione continua della qualità del codice e aumenta drasticamente il ROI di un progetto di sviluppo. Il concetto chiave nell’ispezione continua è trovare i problemi presto, quando risolverli è ancora economico e facile. Con questo modello, gli audit automatizzati del codice analizzano il codice di un progetto lungo più assi di manutenibilità, testano i bug e li confrontano con gli standard di codifica del team.

Gli audit sono completati *con strumenti che rilevano questi problemi direttamente nell’ambiente dello sviluppatore, qualcosa come il correttore ortografico di Microsoft Word.I membri del team ricevono un avviso non appena vengono rilevati nuovi problemi in modo che possano essere affrontati il più rapidamente possibile, mentre il codice è ancora fresco nella mente dello sviluppatore. La tempestività di questi avvisi ha il vantaggio aggiuntivo di consentire ai programmatori di eliminare le cattive abitudini e guidarli verso quelli buoni.

Cosa tenere a mente?

Qui di seguito ti lasciamo 10 principi di controllo continuo in modo da poter applicare da subito:

  1. Tutte le parti coinvolte nel processo di sviluppo - non solo gli sviluppatori o gli amministratori - devono avere accesso immediato a dati significativi sulla qualità del software.

  2. La gestione della qualità del software dovrebbe essere una preoccupazione di tutti fin dall’inizio dello sviluppo, ma è la responsabilità ultima del team di sviluppo.

  3. La qualità del software deve far parte del processo di sviluppo, il che significa che soddisfare gli standard di qualità è uno dei requisiti più severi per poter dichiarare lo sviluppo completo.

  4. I requisiti di qualità del software devono essere obiettivi e non richiedere una decisione soggettiva di approvazione/rifiuto.

  5. Per quanto possibile, i requisiti di qualità del software dovrebbero essere comuni a tutti i prodotti software, indipendentemente dalle specifiche.

  6. Los datos de calidad del software deben estar actualizados, es decir, medidos en la última versión del código.

  7. Los productos de software deben inspeccionarse continuamente, de modo que los errores se encuentren rápidamente, cuando sean fáciles de corregir. Los desarrolladores deben ser capaces de detectar nuevos defectos de calidad tan pronto como se introduzcan, es decir, dentro del IDE mientras escriben el código, de forma similar a cómo los correctores ortográficos resaltan los errores.

  8. Ya sea a través de push o pull, las partes involucradas deben recibir alertas cuando se inyectan nuevos defectos de calidad, ya sea enviando un correo electrónico, rompiendo la compilación o por otros métodos. Se debe realizar un seguimiento de la inyección de nuevos problemas, lo que permite a los equipos tomar decisiones rápidas e informadas sobre la calidad.

  9. Los datos de calidad del software deben estar disponibles como valores absolutos (en todos los códigos) y diferenciales (sólo en código nuevo) para que el equipo de desarrollo pueda tener el control total del flujo entrante de issues.

  10. A todos los problemas nuevos y los problemas críticos existentes se les debe asignar una ruta clara y un plazo de tiempo para su resolución.

L’ispezione continua si adatta bene agli ambienti di sviluppo Agile e a cascata, affrontando le carenze dell’approccio tradizionale. L’ispezione continua offre una qualità migliorata con un’interruzione minima del processo di sviluppo e della timeline.

Questo articolo è stato creato da questo whitepaper di Sonar


bitegarden team

Helping companies to develop better software

Torna al blog