Panoramica del processo di lavoro ALM

Nel processo di lavoro ALM, le richieste sono risolte da attività e operazioni completate.

I package e lo schema ALM (Application Lifecycle Management) mettono a disposizione un processo 'pronto per l'uso' che consente di utilizzare Rational ClearQuest per tracciare il lavoro del proprio team su un release del prodotto. ALM utilizza ruoli definiti, tipi di record e modelli di transizione di stato per facilitare la gestione del processo di sviluppo del software dall'inoltro dei requisiti attraverso lo sviluppo, la gestione del build e l'esecuzione del test.

Un processo ALM tipico è il seguente:

  1. Un cointeressato inoltra una richiesta relativa a un progetto software. Il cointeressato potrebbe essere uno sviluppatore, un tester, uno scrittore, un addestratore, un responsabile prodotto, un rappresentate assistenza clienti o altro membro del team del progetto o utente del prodotto. Una richiesta può avviare una modifica al progetto software. Una richiesta può essere un difetto, una RFE (request for enhancement) o un'operazione.
  2. Un team di selezione esamina la richiesta e decide se accettarla o rifiutarla. Se la richiesta viene accettata, l'amministratore di selezione crea una o più operazioni (una per progetto) che descrivono ad alto livello il lavoro richiesto per soddisfare la richiesta.
  3. Lo sviluppatore principale di ogni progetto esamina l'operazione e valuta il lavoro richiesto per implementarla. Egli quindi attiva l'operazione e crea le attività necessarie per completare l'operazione, ad esempio:
    • Attività di sviluppo (Dev)
    • Attività di test (Test)
    • Attività di valutazione documentazione (Doc Assess)

    Lo sviluppatore principale assegna l'attività Dev a uno sviluppatore.

  4. Il tester principale esamina l'operazione e attività di test quindi assegna quest'ultima a un tester. Il responsabile della documentazione esamina l'operazione e attività di valutazione della documentazione quindi assegna quest'ultima a uno scrittore.
  5. Lo sviluppatore lavora sull'attività di sviluppo e apporta le modifiche necessarie ai file. Egli quindi sposta l'attività di sviluppo nello stato Completed.
  6. Il tecnico release crea un nuovo record baseline che seleziona l'attività appena completata e la relativa serie di modifiche associate.
  7. Il tecnico release esegue la build del progetto utilizzando la baseline appena creata. Egli crea un record build che identifica la baseline utilizzata e indica se la build ha avuto esito positivo o negativo.
  8. Il tester installa ed esegue il test della build. Quando la build supera con esito positivo tutti i test, il tester sposta l'attività di test nello stato Completed.
  9. Lo scrittore valuta l'impatto dell'operazione sulla documentazione e apporta tutte le modifiche necessarie. Egli quindi sposta l'attività di valutazione documentazione nello stato Completed.
  10. Il tester principale esamina l'operazione, vede che le attività necessarie sono state completate e sposta l'operazione nello stato Completed. In alternativa, egli crea ulteriori attività o commenti sulle attività esistenti, se deve essere eseguito ulteriore lavoro.
  11. Il cointeressato che ha inoltrato la richiesta la esamina e vede che una o più operazioni associate sono state completate. Egli può aprire l'operazione ed esaminare la risoluzione. Dall'interno del modulo record operazione, il cointeressato può aprire le attività associate ed esaminare i dettagli del lavoro di sviluppo, di documentazione e di esecuzione test eseguito per completare l'operazione. Se tutto sembra soddisfacente, egli accetta la richiesta e la sposta nello stato Completed. Altrimenti, la può rifiutare e aggiungere un commento sull'operazione, che viene notificato al tester principale via e-mail, indicando l'ulteriore lavoro da eseguire.

Feedback