Preparare il piano di consegna del codice sorgente [chiuso]

12

Chiuso . Questa domanda deve essere più focalizzata . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che si concentri su un problema solo modificando questo post .

Chiuso 4 anni fa .

La nostra azienda sta per acquisire un codice sorgente di un enorme prodotto.

Quali sono gli aspetti da prendere in considerazione quando inizia la consegna, per essere sicuri di avere tutto ed essere in grado di mantenere quel prodotto in futuro?

documentation maintenance knowledge-transfer

— Ahmed Aswani
fonte

1

Se possibile, richiedere l'acquisizione per alcuni degli ingegneri che lavorano al progetto. Questo aiuterà con il problema della continuità delle risorse.

— tehnyit,

non siamo abbastanza fortunati. non possiamo farlo, il massimo che possiamo fare è rendere disponibile un ingegnere per 3-4 settimane.

— Ahmed Aswani,

Ho trovato una risposta correlata, penso che completa la maggior parte delle risposte qui.

— Ahmed Aswani,

8

Innanzitutto buona fortuna.

Ecco alcune delle cose che probabilmente dovresti chiedere / ricevere.

Elenco dei difetti noti.
Elenco dei record di incidenti e problemi.
Dettagli sulle ultime due versioni come; quanto tempo hanno impiegato per implementare, c'è stato un periodo di aumento degli incidenti dopo il rilascio, ecc.
Chi sono gli esperti chiave in materia.
Quali sono gli orari di apertura e il supporto primario.
Da quanto tempo esiste il prodotto e quanto è stabile la base di codice.
Qual è la roadmap del prodotto.
Qual è lo stack tecnologico.
Quali sono i punti di integrazione e chi supporta i sistemi integrati.
C'è qualche componente DR?
Chi è responsabile per invocare DR
Quali sono gli SLA dell'applicazione o gli obiettivi del servizio.
Qual è la crescita prevista delle file di file system / database / code dei messaggi.
Quando vengono eseguiti i backup di sistema, chi è responsabile e qual è la strategia di ripristino.
Chi è responsabile della gestione del portafoglio ordini del prodotto.
Quali sono gli SLA del fornitore e i dettagli di contatto.
Esistono programmi batch o processi di lunga durata.
Il sistema è completamente transazionale e come viene gestita la concorrenza.
Qual è il principale processo di gestione degli incidenti per l'applicazione.
Cosa, quando, chi e in che modo le parti interessate vengono informate di modifiche e interruzioni.
Quali sono i periodi / periodi di interruzione concordati.
Dov'è conservato il codice sorgente.
Come viene eseguito il backup, il ripristino e il registro delle modifiche del codice sorgente.
Dove, cosa e chi possiede l'architettura della soluzione.
Qual è il target di distribuzione (DEV, ST, UAT, Pre PROD, PROD, DR).
Quando vengono rinnovate le licenze di terze parti.
Esiste un grafico RACI
Quanti utenti ci sono e dove si trovano.
Quali sono i problemi di risoluzione dei problemi comuni o i reclami.
Chi è responsabile della concessione dell'accesso al sistema.
Quando vengono effettuati i test pent / gli audit di sicurezza.
Dov'è l'IC e il processo di compilazione automatizzato.
Chi è responsabile dell'amministrazione del controllo del codice sorgente e del server di compilazione.
Dove sono le guide all'installazione.
Esiste documentazione per l'infrastruttura e la rete di destinazione.
Quali sono i tipi di gravità e impatto dei recenti incidenti.
Esistono istruzioni per l'installazione della workstation per sviluppatori.
- Quali ausili allo sviluppo e framework vengono utilizzati e sono autorizzati per il tuo team.

Questo è tutto ciò a cui riesco a pensare al momento.

— Kane
fonte

8

Definire "DR", "DEV, ST, UAT, Pre PROD, PROD, DR" e "RACI". Si noti che parte di questo è irrilevante per il codice sorgente (vale a dire, i grafici RACI sono organizzativi, non correlati al codice).

— Lott

Vorrei avere accesso al repository whoel del codice sorgente non solo alle versioni correnti del codice sorgente. I commenti in questo ti diranno spesso perché il codice è stato modificato in un modo particolare. Questo è importante per iknwo per mantenerlo.

— HLGEM,

@HLGEM mi dispiace che la mia affermazione sulle versioni correnti del codice sorgente abbia implicato (almeno per me) il codice sorgente completo per tutti i componenti.

— Kane,

@ S.Lott DR viene utilizzato per descrivere il "ripristino di emergenza". Dev è un termine comune per "Ambiente di sviluppo", qualunque cosa sia composta per il tuo ambiente. ST è un'abbreviazione per System Testing Environment. Non sono d'accordo sul fatto che RACI sia uno strumento organizzativo in quanto viene utilizzato per descrivere chi è responsabile, responsabile, informato e consultato. Quindi, quando viene impegnato il codice, chi ne è responsabile? Chi viene consultato nell'ambito di una peer review? Chi viene informato che una build è riuscita / fallita? E così via

— Kane,

@kame: aggiorna la risposta con le definizioni. Si prega di non aggiungere altri commenti alla risposta. Si prega di aggiornare la risposta.

— S.Lott

6

Quali sono gli aspetti da prendere in considerazione quando inizia la consegna, per essere sicuri di avere tutto ed essere in grado di mantenere quel prodotto in futuro?

Le cose che dovresti assicurarti sono:

li vedi costruire il codice con successo
li vedi costruire test unitari e far passare tutto
li vedi eseguire altri test con successo e tutti passano (accettazione, integrazione, ecc.)
ottieni il database di problemi aperti (facile da ottenere se usano bugzilla o simili)
il prodotto funziona (istruzioni per l'installazione).

Tutto il resto spetta all'attuale manutentore.

— BЈовић
fonte

2

Suggerirei che questi vengano modificati per avere le parole "Devi vederli ..." ad es. "Devi vederli costruire il codice" e "Devi vederli eseguire i test unitari", ecc. Le prove sono importanti qui.

— S. Lott,

@ S.Lott Che si tratti di mostrare o scrivere in un documento, non dovrebbe importare. Ahmed Aswani e il suo team manterranno l'applicazione e dovrebbero essere in grado di fare tutto il passo sopra da soli. Ho modificato un po 'la risposta, ma non sono sicuro che sia quello che hai suggerito.

— BЈовић

1

Un'affermazione secondo cui il codice viene creato non è la stessa cosa che vedere effettivamente ottenere il codice. Stato lì. Fatto. La documentazione può essere vaga, confusa o incompleta. È il vecchio principio "Fidati ma verifica". Fino a quando non lo vedi, non ci credo.

— S. Lott,

1

@ S.Lott Ok ha senso. Ora che ci penso, ero in una situazione simile prima, dove ci hanno fatto implementare qualcosa su schede HW rotte. Abbiamo trascorso 4 mesi buoni prima di capire cosa è veramente sbagliato.

— BЈовић,

5

È necessario assicurarsi che il team consegni il codice fornirà supporto per un periodo di tempo. Trasformalo in un contratto firmato!

In seguito avrai domande che non sapevi che dovevi porre in anticipo, quindi hanno bisogno di "restare in giro" per spiegarti le cose non solo dare il codice, i documenti e tutto ciò che hanno sul progetto.

Quando hai una consegna del progetto perdi una cosa importante: l'esperienza del team originale.

A volte ottieni anche qualcosa che non ti aspettavi: la loro ostilità.

La società sta facendo il passaggio delle consegne sta ottenendo un buon affare con la consegna? Se perdono gli affari perché rivolgono a te il progetto, gli (orgogliosi) sviluppatori che hanno creato il codice potrebbero risentirsi del fatto che il loro "bambino" viene dato via. Potresti ricevere risposte come: "È nei documenti che hai" ... anche se non lo è.

Gli aspetti tecnici sono utili da affrontare, ma tengono anche conto del lato umano.

YMMV!

— JohnDoDo
fonte

0

Il codice viene fornito con una suite di test? Tutti i test nella suite di test superano? Quanta copertura ha la suite?

Vorrei raccomandare che, mancando una suite di test, la costruzione della suite di test e del relativo framework sia la vostra priorità.

— blueberryfields
fonte