E i sistemi ALM, gli ERP e i prodotti incorporati?

4

Stiamo lavorando per ottenere un nuovo sistema di gestione del ciclo di vita delle applicazioni (ALM), compreso un bug tracker, un sistema di documentazione, la gestione dei progetti, ecc.

La preoccupazione è che ci occupiamo di sistemi embedded piuttosto complessi e vorremmo avere la migliore integrazione possibile dei diversi servizi (gestione dei progetti, rilevamento di problemi / attività, documentazione, ecc.). Se si trattasse solo di software, acquisterei solo qualcosa come JIRA, ma il fatto che ci piacerebbe poter gestire software, firmware (senza grossi problemi) e hardware nello stesso sistema mi fa dubitare un po '.

Sto cercando consigli su questi punti:

  • Che ne pensi di gestire "bug" con prodotti incorporati? Nel software, hai le versioni dei moduli interessati. Nei prodotti incorporati, si ha una diversa guida del software spesso volte firmware diversi che operano a volte hardware diverso. È utile in pratica considerare semplicemente le parti hardware come se fossero moduli software in un sistema destinato al software? Tendo a credere che aggiungerà molti campi personalizzati all'interfaccia di tracciamento dei bug e di conseguenza non ne promuoverà l'uso sistematico.
  • Alcuni vorrebbero spingere l'integrazione al livello in cui l'inventario hardware è integrato al resto. Ciò significa che un progetto in ALM (pensa JIRA) dovrebbe riservare i suoi componenti hardware in base ai sottocomponenti. Significa anche che, ad esempio, l'ALM in questione dovrebbe essere in grado di gestire i fornitori di parti e offrire servizi per la creazione, l'invio e la gestione degli ordini di acquisto in generale.

Mi chiedo, a quel punto, se tutto in un processo di gestione del progetto incorporato può essere integrato in un sistema di gestione, o se deve essere tracciata una linea tra 1) bug / tracciamento delle attività (possibilmente software e hardware) e gestione del progetto e 2) gestione di progetti di alto livello, tracciamento delle scorte, ordini di vendita / acquisto, ecc. Ciò che alla fine è auspicato sembra non essere altro che un JIRA e un ERP integrati. O è possibile fare un ALM corretto in un ERP esistente o avere già un ERP decente in un sistema ALM?

La mia opinione personale, da quello che so ora, sarebbe quella di dividere i problemi e la gestione dei progetti (ALM + documentazione + ...) dall'ERP. Il problema è che c'è documentazione su un progetto sia nell'ERP che nella gestione del progetto dell'ALM (che verrebbe utilizzato per software, firmware, hardware, ...). Ciò che è divertente in questo è che alcune cose potrebbero sembrare molto estranee all'inizio, come i fogli di tempo (ERP) e un problema (bug tracker in ALM), ma alla fine, potrebbe essere molto interessante, voluto o addirittura richiesto sapere quanto tempo è stato dedicato a un bug o a un progetto (bug, problemi, funzionalità, altri compiti). Questo dà un punto verso l'unificazione totale di ERP / ALM ...

A questo punto dovresti avere un'idea delle mie domande. Qualsiasi input utile è molto apprezzato. Grazie!

    
posta Joanis 14.12.2011 - 07:51
fonte

1 risposta

2

Ho lavorato per l'azienda sviluppando dispositivi embedded per la registrazione sismica, inclusi hardware, firmware e software personalizzati.

È emerso che solo un sistema di tracciamento dei problemi convenzionale, come RedMine (cosa abbiamo usato) o JIRA (come suggerisci) già perfettamente.

Non sono competente in JIRA, ma in RedMine puoi definire le "aree" del tuo progetto, quindi abbiamo diviso il progetto completo in tre parti principali: hardware, firmware e software. RedMine ti permette di cambiare l'area "al volo", che è particolarmente utile se si nota un bug e non si conosce la sua origine, si può semplicemente postarlo come un bug generale e quindi gli sviluppatori responsabili di firmware o ingegneri hardware possono assegnarlo alla sezione appropriata.

    
risposta data 14.12.2011 - 10:19
fonte