finestra.dataLayer = finestra.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-921TFQBWCD');

Blog

Articoli scritti principalmente dal team di ScopeMaster sull'analisi dei requisiti software, sul dimensionamento e sul QA. Ci auguriamo che questi articoli siano utili.

Benchmarking del software e benchmark appropriati

Benchmark software per la prevedibilità del progetto Vuoi confrontare il tuo rendimento con quello degli altri, internamente o con i team di altre organizzazioni. Per i confronti tra team interni puoi stabilire i tuoi benchmark interni, mentre per il confronto con altri team nel settore del software, cercherai benchmark del software del settore. Questo articolo si concentra sul benchmarking appropriato [...]

Grandi progetti software: successo

I grandi progetti software sono molto soggetti a ritardi e persino al fallimento. Per avere successo, sono necessari un'attenta pianificazione, una comunicazione efficace, un elevato livello di competenza tecnica e attenzione alla qualità per superare molte di queste sfide. Lo Standish Chaos Report e il Cost of Poor Quality Report 2022 del gruppo CISQ sono entrambi [...]

Rielaborazione su progetti software

Spiegazione della rilavorazione del software La rilavorazione del software è il lavoro consequenziale che deriva dalla modifica di requisiti, progetti, codice e test dopo che un lavoro è già stato avviato. Nella maggior parte delle aziende software ciò rappresenta 30-50% di tutta l'attività. Generalmente escludiamo la correzione di bug dalla categoria delle rielaborazioni del software. La rilavorazione generalmente descrive l'extra [...]

Debito Tecnico – Stima e Costi

Il significato e l'origine del "debito tecnico" La metafora del debito tecnico (TD) nel contesto del software è stata coniata da Ward Cunningham che all'epoca stava lavorando alla codifica di un sistema finanziario. Ha usato la metafora per spiegare ai suoi colleghi finanziari le ragioni per il refactoring e la riscrittura di parti di codici poiché la conoscenza [...]

Difetti dei requisiti: il valore di trovarli tempestivamente

Di seguito sono riportati alcuni approfondimenti sull'importanza di individuare i difetti dei requisiti prima della progettazione o della codifica. Per un team di sviluppo software è molto utile individuare tempestivamente i difetti. Ancora meglio è prevenire del tutto i difetti. Requisiti eccellenti sono una forma efficace di prevenzione dei difetti e di rilavorazione. Un requisito ambiguo […]

Suddivisione della storia: linee guida e suggerimenti

Suddivisione della storia: perfezionamento fino ad una granularità ottimale Una storia apparentemente piccola potrebbe rivelarsi molto più grande del previsto. Solo perfezionando o suddividendo la storia puoi scoprirlo. La suddivisione della storia può essere effettuata all'inizio o subito prima dello sprint precedente. Ti consigliamo di farlo il prima possibile [...]

Elicitazione dei requisiti: potenziata con l'intelligenza artificiale

L'individuazione dei requisiti riguarda la scoperta dei reali requisiti aziendali e dei requisiti di sistema di qualsiasi progetto software. Si tratta innanzitutto di scoprire ciò che è necessario e poi di articolare le scoperte distillate in artefatti che possono essere utilizzati come base per descrivere ciò che deve essere fatto. È insolito che il vero [...]

Garanzia di qualità della storia dell'utente: automatizzata

Vediamo come e perché potremmo voler garantire la qualità delle storie degli utenti. Le storie degli utenti inadeguate portano a riunioni inutili, sprechi e rielaborazioni. Migliorare la storia dell'utente il più presto possibile nel ciclo di vita dello sviluppo è un modo efficace per ridurre al minimo gli sprechi e le rielaborazioni. L’assicurazione della qualità è un processo sistematico [...]

Software IV e V

Verifica e validazione indipendente di progetti software IV e V stanno per validazione e verifica indipendente. Definizione: Secondo NIST IV&V è: una revisione, un'analisi e un test completi (software e/o hardware) eseguiti da una terza parte obiettiva per confermare (ovvero verificare) che i requisiti siano definiti correttamente e per confermare (ovvero, validare) che il sistema sia correttamente [...]

Vai in alto