|
Il forum sulla Qualità di QualitiAmo Torna all'homepage di QualitiAmo
|
Precedente :: Successivo |
Autore |
Messaggio |
MrTetris Nuova recluta del forum
Registrato: 12/03/14 13:05 Messaggi: 7
|
Inviato: Lun Ott 29, 2018 1:41 pm Oggetto: Tracciabilita' nel medical software development process |
|
|
Buongiorno a tutti.
Al momento sto partecipando a uno studio di fattibilità sul passaggio da TFS a PTC Integrity per un’azienda che sviluppa software medicali, e sto cercando di capire quali siano i requisiti di base da rispettare per quanto riguarda la tracciabilità degli elementi del Software Development Process.
Gli elementi individuati finora sono:
Project (ovviamente il titolo del progetto, e l’elemento di più alto livello)
Backlogs (una sorta di whishlist proveniente dal PdM)
Design Input (definiti dal PdM in accordo con il SA)
User Interface specifications (definiti dal PdM in accordo con il SA)
Risks (definiti da PdM e PjM)
Requirements (scritti dal SA)
Tasks (scritti e implementati dal SE, se ritiene che il Requirement non sia abbastanza dettagliato o che sia opportuno scomporlo in più parti)
Test cases (scritti ed eseguiti dal QA)
Bugs (scritti dal QA, risolti dal SE)
Change Requests (scritti e approvati da PdM e PjM)
La risposta non mi sembra scontata, e certamente dipende dal nostro QMS e dalla Risk Analysis del specifico software (di classe B secondo la 62304).
Al momento, la mia proposta sarebbe la seguente (considerate che tutti gli elementi sarebbero poi tracciati al “Project”):
http://depositfiles.com/files/t2w09mgar
Traducendo lo schema in parole:
I Backlogs non devono essere tracciati, perché il reale punto di partenza sono i Design Input in cui gli stessi Backlogs vengono analizzati ed elaborati (o eventualmente eliminati).
Gli UI specifications devono essere tracciati a un Design Input di più alto livello, così come i Change Request devono essere tracciati al Design Input/UI spec originario e al Requirement che li definisce nel dettaglio.
Per ogni DI, UI spec e CR deve essere definito almeno un Requirement, e viceversa (questo è uno dei punti chiave, perché altri hanno proposto che la creazione di un Requirement non implichi l’esistenza di un elemento di più alto livello a monte. Io però non riesco a immaginare nessun caso in cui questo possa essere ritenuto non necessario).
I Tasks sono creati dai Software Engineers se preferiscono scomporre o dettagliare ulteriormente il corrispondente Requirement, ma è quest’ultimo che viene testato tramite Test Case, non i singoli Tasks.
Ogni Requirement è tracciato ad almeno un Test Case per il test, ma viceversa i Test Case possono essere creati anche in risposta a un Bug trovato in fase di Exploratory Testing (in questo caso, creiamo il Test Case solo se il Bug è legato a un Rischio, altrimenti il Bug resta tracciato semplicemente al Project).
Mi chiedo anche se in questo caso non sia necessario legare il Test Case al Risk, o se possiamo evitare (al momento i Risk non sono legati a nessun altro elemento perché così si è sempre fatto in passato, e perché non sarebbe facile stabilire una regola valida per ogni caso. Al massimo proporrei che se un Bug trovato in fase di Exploratory Testing ha un impatto su un certo rischio, allora il Test Case creato per il Bug deve essere tracciato al corrispondente Risk).
Sarei curioso di sapere cosa ne pensate della mia proposta e come vi comportereste con i Risk, considerando anche che i collegamenti necessari per estrapolare la Traceability Matrix devono essere definiti manualmente (generalmente dal SA). Quindi meno sono le tracce obbligatorie richieste, e meno possibilità di errore avremo in futuro.
Grazie a tutti per le risposte.
P.S. precedentemente a questo avevo creato un topic del tutto analogo, ma avendo utilizzato una lettera accentata nel titolo risulta inaccessibile e non ho modo di modificarlo. Scusate.
Prego i moderatori di eliminarlo. |
|
Top |
|
|
|
|
|
|
Non puoi inserire nuovi argomenti Non puoi rispondere a nessun argomento Non puoi modificare i tuoi messaggi Non puoi cancellare i tuoi messaggi Non puoi votare nei sondaggi
|
|